OS and version
SMP Debian 6.1.128-1 (2025-02-07)
Bug
We’re implementing the smallest possible CorePass login flow via QR (no full OIDC/Connector backend yet).
Goal: User scans a corepass:login QR and the CorePass app calls back our endpoint with coreID (+ signature, session). We then read the wallet on XCB Devin Testnet.
Despite the app recognizing the QR, no callback ever arrives (neither type=callback POST nor type=app-link GET).
This feels like either a bug in the protocol implementation or undocumented mandatory parameters (e.g. client_id).
Reproduce Bug
see additional context
Expected behavior
see additional context
Commit hash
No response
Additional context
Environment
- Domain:
https://qrmini.mydomain.de
- Callback endpoint:
https://qrmini.mydomain.de/api/cp-login
- Server: Node.js v22.19.0, Express, port 3200 (behind nginx + Let’s Encrypt)
- Blockchain: Core (XCB), Devin Testnet
- Date/Time (Europe/Berlin): 12 Sep 2025
What we implemented (minimal demo)
Frontend (QR generation)
const session = "sess-" + Math.random().toString(36).slice(2,12);
const conn = "https://qrmini.mydomain.de/api/cp-login";
const cpLink =
"corepass:login"
+ "?sess=" + encodeURIComponent(session)
+ "&conn=" + encodeURIComponent(conn)
+ "&type=" + "app-link" // also tested "callback"
+ "&scope=" + "openid"
+ "&state=" + encodeURIComponent(session);
// → QRCode.toDataURL(cpLink) …
Backend (Node/Express)
app.post("/api/cp-login", (req, res) => {
const { session, coreID, signature } = req.body || {};
console.log("📩 CorePass POST:", { session, coreID, signature });
if (!session || !coreID) return res.status(400).json({ ok:false, error:"missing" });
sessions.set(session, { coreID, signature });
res.json({ ok: true });
});
app.get("/api/cp-login", (req, res) => {
const { session, coreID, signature } = req.query;
if (session && coreID) {
console.log("📩 CorePass GET (app-link):", { session, coreID, signature });
sessions.set(session, { coreID, signature });
}
if (!req.query.session) return res.json({});
res.json(sessions.get(req.query.session) || {});
});
Expected behavior
Actual behavior
-
App scans QR successfully.
-
No POST/GET with payload is received by the server.
-
nginx logs only show browser polling requests:
"GET /api/cp-login?session=sess-abc123 HTTP/1.1" 304 …
-
Node console never logs 📩 CorePass POST nor 📩 CorePass GET.
Questions
-
Is a client / client_id parameter mandatory for the QR protocol?
- If yes: How can developers obtain one?
- We couldn’t find a “Create Connector / Create Client” flow in public docs.
-
What are the minimal required query parameters for a QR that actually triggers a callback?
- Currently using:
sess, conn, type, scope, state.
-
Callback payload schema:
- What exact fields are sent by the app (POST vs GET)?
-
Signature verification:
- How should the
signature be verified server-side?
-
Docs status:
- If a Connector/client_id is a hard requirement, could you please clarify this in the documentation and describe how to request or register one?
Notes
- HTTPS is fully working (
Let’s Encrypt, TLSv1.3).
- Endpoint tested with curl: works fine (
200 OK).
- Using both domain and direct IP in
conn produced the same result (no callback).
Closing
If this is expected behavior (i.e. a client_id is mandatory), then this is not a bug but missing documentation. In that case, please clarify the requirements and process to obtain/register a client_id.
Thanks a lot! We’re happy to provide more logs or contribute a minimal working guide once we know the correct setup.
OS and version
SMP Debian 6.1.128-1 (2025-02-07)
Bug
We’re implementing the smallest possible CorePass login flow via QR (no full OIDC/Connector backend yet).
Goal: User scans a corepass:login QR and the CorePass app calls back our endpoint with coreID (+ signature, session). We then read the wallet on XCB Devin Testnet.
Despite the app recognizing the QR, no callback ever arrives (neither type=callback POST nor type=app-link GET).
This feels like either a bug in the protocol implementation or undocumented mandatory parameters (e.g. client_id).
Reproduce Bug
see additional context
Expected behavior
see additional context
Commit hash
No response
Additional context
Environment
https://qrmini.mydomain.dehttps://qrmini.mydomain.de/api/cp-loginWhat we implemented (minimal demo)
Frontend (QR generation)
Backend (Node/Express)
Expected behavior
For
type=callback: CorePass app sends POST JSON{ "session": "sess-123", "coreID": "xcb1…", "signature": "…" }For
type=app-link: CorePass app sends GET with query parametersActual behavior
App scans QR successfully.
No POST/GET with payload is received by the server.
nginx logs only show browser polling requests:
Node console never logs
📩 CorePass POSTnor📩 CorePass GET.Questions
Is a
client/client_idparameter mandatory for the QR protocol?What are the minimal required query parameters for a QR that actually triggers a callback?
sess,conn,type,scope,state.Callback payload schema:
Signature verification:
signaturebe verified server-side?Docs status:
Notes
Let’s Encrypt, TLSv1.3).200 OK).connproduced the same result (no callback).Closing
If this is expected behavior (i.e. a client_id is mandatory), then this is not a bug but missing documentation. In that case, please clarify the requirements and process to obtain/register a client_id.
Thanks a lot! We’re happy to provide more logs or contribute a minimal working guide once we know the correct setup.