Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Session event emits the customer's MAC address in the p tag — spec-invalid value on every payment response

Đã đóng Phù hợp với người mới
  • Có gì không ổn?
#949 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@Amperstrand đang làm issue này rồi.

Từ ngày 16/10/2026.

  • #951 của @Amperstrand — đang mở

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
70/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go
Lĩnh vực
backend

Hướng nghiên cứu

Bắt đầu từ createSessionEvent trong src/merchant/merchant.go, nơi sự kiện kind-1022 đặt customerPubkey vào thẻ p, và tại nơi gọi duy nhất của nó trong PurchaseSession, hàm truyền địa chỉ MAC. Xóa thẻ p khỏi sự kiện phiên và giữ nguyên device-identifier. Trước khi chỉnh sửa, hãy dùng grep trong các bộ kiểm tra tuân thủ của portal và PRTA để tìm bất kỳ bên nào đọc thẻ p, vì issue nói rằng điều này hiển thị trên đường truyền. Hoàn thành khi sự kiện phiên không còn thẻ p và các bài kiểm thử của gói merchant vẫn chạy đạt.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Found while resolving the spec divergence tollgate#16 (spec PR: tollgate#26).

Evidence

createSessionEvent in src/merchant/merchant.go declares a customerPubkey parameter and puts it straight into the kind-1022 session event's p tag:

func (m *Merchant) createSessionEvent(session *CustomerSession, customerPubkey string) (*nostr.Event, error) {
    deviceIdentifier := session.MacAddress
    ...
    Tags: nostr.Tags{
        {"p", customerPubkey},
        {"device-identifier", "mac", deviceIdentifier},

Its only call site passes the MAC address (src/merchant/merchant.go, PurchaseSession):

sessionEvent, err := m.createSessionEvent(session, macAddress)

So every payment response carries the customer's MAC in p — a value that is not a Nostr pubkey. Consequences: #p relay-side filtering of session events can never match anything; any spec-conformant consumer validating p as a pubkey rejects our session events; and the MAC — which device-identifier already carries — is duplicated into a field whose contract says pubkey.

Why it happens

Pre-March-2026 the payment was a signed kind=21000 event, so a customer pubkey existed. The raw-token rework removed the identity source; the parameter was never revisited.

Suggested fix

In the raw-token flow there is no customer Nostr identity, so the spec-conformant behavior is to omit the p tag (the spec PR above makes p conditional and forbids non-pubkey values in it). If the legacy kind=21000 envelope ever carries a verified customer pubkey, that is the one case where p could be filled.

Note the change is wire-visible on every successful payment response (the shipped portal and PRTA conformance suites should be checked for anything reading the p tag — grep suggests the portal keys on allotment/metric, but that is worth confirming in review, not assuming).

Also noted there

The same function emits a start-time tag TIP-01 does not document — flagged on the spec PR as a separate documentation proposal, not part of this fix.

Ngôn ngữ chính
Go
Star
12
Fork
14
Merge trung bình
1 ngày 8 giờ
Pull request đã merge (30 ngày)
201

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của OpenTollGate/tollgate-module-basic-go

Tất cả issue của OpenTollGate/tollgate-module-basic-go

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.