Well, it seems to have resolved the issue! Many thanks for your help Alexander, I appreciate it! 👍

I would say despite the "important note", it is not obvious this requirement applies to this situation, and it appears in a different part of the documentation from the one on JWT (https://docs.intersystems.com/iris20241/csp/docbook/Doc.View.cls?KEY=ROA...), so linking the 2 articles is not immediate. A note in the JWT article would be nice.

My client is on 2023.1 anyway, so the fix is not in there. Is there a way to make it work? Or is there a (reasonably simple) way to produce a JWT bearer token in the dispatch class' code (after password authentication)?

Thanks

Exact same behavior on 2024.1, same traces in ISCLOG.

A few things revealed by the ISCLOG logging:

• If "allowed authentication methods" is set to "password" only, the system seems to attempt to log in a user (during the OPTIONS interaction) and fails:

**CSPServer-2 2024-07-23 14:27:57.214638 ns=USER routine=%SYS.cspServer job=44424 tag=F20 sessionid=hgxRMlcT0W
[CSPLogin] Error: Reverting to prelogin security context. (822  )
 ¦0   6 USER …(e^AuditLoginFailure+87^%SYS.SECURITY^1%e^UsersCSPLogin+135^%SYS.SECURITY^1!e^CSPLogin+102^%SYS.cspServer^1$e^CSPDispatch+883^%SYS.cspServer^1$d^CSPDispatch+881^%SYS.cspServer^1%d^ProcessRequest+1^%CSP.Session.1^1!d^Request+683^%SYS.cspServer2^1 d^Request+25^%SYS.cspServer2^1%d^ProcessRequest+1^%CSP.Request.1^1d^css+21^%SYS.cspServer2^1 d^SuperServer+60^%SYS.SERVER^2d^^^0

**CSPServer-2 2024-07-23 14:27:57.2146733 ns=USER routine=%SYS.cspServer job=44424 tag=F20 sessionid=hgxRMlcT0W
[LoginFailed]Security error: 0   6 USER …(e^AuditLoginFailure+87^%SYS.SECURITY^1%e^UsersCSPLogin+135^%SYS.SECURITY^1!e^CSPLogin+102^%SYS.cspServer^1$e^CSPDispatch+883^%SYS.cspServer^1$d^CSPDispatch+881^%SYS.cspServer^1%d^ProcessRequest+1^%CSP.Session.1^1!d^Request+683^%SYS.cspServer2^1 d^Request+25^%SYS.cspServer2^1%d^ProcessRequest+1^%CSP.Request.1^1d^css+21^%SYS.cspServer2^1 d^SuperServer+60^%SYS.SERVER^2d^^^0

**CSPServer-2 2024-07-23 14:27:57.2147257 ns=USER routine=%SYS.cspServer job=44424 tag=F20 sessionid=hgxRMlcT0W
[LoginFailed]Redirecting to login page /csp/lspmanagement/login

**CSPServer-2 2024-07-23 14:27:57.2147994 ns=USER routine=%CSP.Request.1 job=44424 tag=F20 sessionid=hgxRMlcT0W
[UpdateURL] Looking up: //localhost/csp/lspmanagement/login path found: //localhost/csp/lspmanagement/ Appl= /csp/lspmanagement/    :%All/csp/lspmanagementUSER„LSP.REST.Management<„

Then gets a <PROTECT> error:

**CSPServer-2 2024-07-23 14:27:57.2153425 ns=USER routine=%SYS.cspServer job=44424 tag=F20 sessionid=hgxRMlcT0W
[callPage] Return Status
0  áŠ]<PROTECT>^%CSP.Login.1 ^|^^c:\intersystems\irishealth202312\mgr\user\|LSP.REST.Management.1 uUSER j^^%CSP.Login.1^0'e^ProcessCorsRequest+8^%CSP.Login.1^1e^zLogin+7^%CSP.REST.1^1$e^CSPDispatch+500^%SYS.cspServer^2$d^CSPDispatch+279^%SYS.cspServer^1%d^ProcessRequest+1^%CSP.Session.1^1!d^Request+683^%SYS.cspServer2^1 d^Request+25^%SYS.cspServer2^1%d^ProcessRequest+1^%CSP.Request.1^1d^css+21^%SYS.cspServer2^1 d^SuperServer+60^%SYS.SERVER^2d^^^0

**CSPServer-2 2024-07-23 14:27:57.2154258 ns=USER routine=%SYS.cspServer job=44424 tag=F20 sessionid=hgxRMlcT0W
[HandleError]: ERROR #5002: ObjectScript error: <PROTECT>^%CSP.Login.1 ^|^^c:\intersystems\irishealth202312\mgr\user\|LSP.REST.Management.1
0  áŠ]<PROTECT>^%CSP.Login.1 ^|^^c:\intersystems\irishealth202312\mgr\user\|LSP.REST.Management.1 uUSER j^^%CSP.Login.1^0'e^ProcessCorsRequest+8^%CSP.Login.1^1e^zLogin+7^%CSP.REST.1^1$e^CSPDispatch+500^%SYS.cspServer^2$d^CSPDispatch+279^%SYS.cspServer^1%d^ProcessRequest+1^%CSP.Session.1^1!d^Request+683^%SYS.cspServer2^1 d^Request+25^%SYS.cspServer2^1%d^ProcessRequest+1^%CSP.Request.1^1d^css+21^%SYS.cspServer2^1 d^SuperServer+60^%SYS.SERVER^2d^^^0

I would think that this attempt at login on the preflight call is incorrect?

• If "Allowed Authentication Methods" is set to "unauthenticated" only, I don't see these errors in ISCLOG, but it still doesn't work as the engine does not process the "allow origin" header. And besides, this is not an acceptable situation as (based on my tests) my API is accessible without authentication in this case.
• I see the same behavior if authentication is set to both unauthenticated and password. It appears to take the "path of least resistance", so no authentication errors in ISCLOG, but the result is the same ("allow origin" is not processed).

So I think we're looking at 2 issues here: the attempt at authentication of the OPTIONS call, which is probably not right? and the fact that the "allow origin" header is not processed.

BTW, how does that work anyway? Is any CORS origin supposed to be accepted for the login API?

I'll see if I can reproduce this on 2024.1, in case.

I'll do that, thanks for the feedback. 👍

Sorry, I had not seen your answer when I responded to John. That was the problem indeed. Thanks for the feedback!

The plot thickens... After activating traces (v9r), I don't see anything being logged on the HTTP trace of the csp GW for VSCode's attempts to access the instance. I do see all the traces for accessing the management portal. It must be something with VSCode's configuration then, but I can't figure out what; after all InterSystems server configuration is very trivial... I restarted VSCode again to be safe, still no cigar. And I can open the SMP in an external browser from VSCode, so the server connection settings must be correct. "Open management portal in tab" does nothing, which is perhaps also significant? (the /csp/sys* apps "use cookie for session" are all on "autodetect", FWIW)

I even tried to disable the windows firewall (since it's all local I don't expect that could be a cause, but you never know...), to no avail.

Good point, I'll try that next. Thanks!

One more piece of info: out of desperation, I tried to change the port on my Apache server, restarted it. Everything works fine on the new port (I tried 8080 and 52774), VSCode (after changing the settings, naturally) still won't connect. So using the default HTTP port is not the issue.

Hi Timo

Thanks for your feedback. Yes, I checked all /api endpoints are enabled and their settings are identical to the 2023.1 instance (they are the installation defaults anyway). They are also declared and active in the web gateway.

Apache's access log gives me this: "HEAD /api/atelier/ HTTP/1.1" 404 - "-" "axios/1.7.2". There's nothing in Apache's error and other logs. I can't find any error in the web gateway's csp.log either. The audit database is clean.

The only thing remotely suspicious on the system is an error message repeated several times in the message log, related to the license server:

LMF Warning:  Could not send login/logout messages to license server (unknown reason = -10|Unknown Server)

But since the portal, Studio and the terminal all work fine I see no reason for this to have any bearing on the issue. To be on the safe side, I changed the license server port and restarted the instance. I'm not seeing that error anymore (for now). But VSCode still won't connect.

The fact that VSCode is getting a 404 (and not a 400, 401, 403 or 5xx) is a bit strange, but I believe I've seen other instances where IRIS returns a 404 when, say, a 401 would make more sense, so I won't get hung up on this being a "not found" error.

FWIW, the InterSystems extension pack for VScode is updated regularly; it is currently on version 1.0.3.

@John Murray 
http://localhost/csp/sys/%25CSP.Portal.Home.zen

Same as for 2023.1 except for the port (one is 52773, the other the default 80)