Yeah maybe we could solve that if we reload the window on puprose after a config change.
Nah, rather not, there are too many other extensions that do not properly resume after the window has been reloaded. I think the cleanest solution would just be to reload the settings every time manually – how expensive can this be today? However, probably we should move this discussion to GitHub. 
Ah, thanks a lot! I very recently found out something similar, see this post:
(However, I don’t understand why you have to specify the access token as user but not as password! I think the common solution is to enter it as password instead. Is OH really following the (in)official standards here?)
Simple answer. The extension currently is capable of handling basic auth and the extension code omits the :password when you just enter a username.
That’s why it has to be in the password field (currently).
Th “latest” vscode extension release is from January so don’t expect too much openHAB 3 adaptions currently.
Good question, some software doesn’t allow empty user names and the token identified the user so I made it the “username” - but on the other hand some other software will log the password in plain text so you can inadvertently leak it. Maybe both options should work…
Yes, I also think both ways should be supported 
Many clients will treat the password as a more sensible data than the username.
ADMIN : NO advertising here !!!
Hello everyone ive just merged to an openhabian pi from my previous widows setup.
I was really struggeling with getting Visualcode to connect. (authentication failure)
AT LAST i changed my OH admin username (users.json) that had an emailadress with an @ to simple “admin”. I dont think OH/visualcode appriciates @ in the username
http://MYUSER:MYPSWD@192.168.31.2:8080/rest/things also trow an authentication fail with my email as username (webui worked fine)
Sucsess!
That’s not OH or vscode, it is the url format that uses @ as a delimiter to separate userinfo from the host. So every (correct working) application thinks " ah yes that’s the end of the user-data. here come the host".
Thank you for the reply
Maybe code first setup of username and passord not to allow @ 
Just wanna give a heads up if anyone else do this mistake migrating to OH3
Are you sure?
Yes, the username inside an URL must not contain an @.
But I would have expected this to work:
"openhab.username": "admin@example.com",
Absoulutly shure, i tested everything else before the AHA moment that the @ was the culprit
At some point we are doing a http request to the rest api (liek for updating the items/things explorer or hovering over an item) in the extension and then it will become part of an url.
I think that’s where thing will get messed up.
Just as a side node:
The usage of @ should probably be fine anyway as a user name. Can’t say something final about this.
There is still the alternative to use a generated token as username in the extension.
That would be prefered option in my view.
It is just a culprit when it come to basic auth without token, which will then lead to the uri problems.
So i would like to avoid checking for an @ if it is finei n some cases.
Hi
I have a similar problem:
OH3 on Linux, behind a reverse proxy (nginx) and VSCode with openHab extension (Windows).
At VSCode with openHab extension a openhab.username and openhab.password for nginx authentication is specified.
So it is not possible, to specify openHab3 basic authentication here.
The result is: items can be read via rest api, but reading things (knx) fails with authentication error.
Before upgrading to openHab3 it was working.
Is there a possibility to configure nginx to do openHab autentication (e.g. via API token), but only for the user specified in VSCode?
Are there other possibilities?
Any hint is welcome!
Thank you.
@Confectrician you should create a parameter specific for the API token and send it in the X-OPENHAB-TOKEN HTTP header, it will be accepted too. That way you have the Authorization header free for Basic authorization.
Filed an issue as reminder.
https://github.com/openhab/openhab-vscode/issues/233
We could try this as workaround.
I would like to not invest too much time in this.
Our http lib (request-promise) is deprecated and i would like to replaces that completely,
when working on a proper authentication.
(Best case would be a suitable oauth implementation of course. That should be the long term goal.)
Thank you!
I solved my problem using your hints:
I added a second locaton in my nginx config:
location /rest/ {
proxy_pass http://localhost:8080/rest/;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Authorization “Basic base64 encoded name:password”;
}
So VSCode can use the credentials for nginx authentication and nginx send base64 encoded openhab credentials
Not sure how this helped you, but ok
You really shouldn’t do basic auth to authenticate to openHAB though, that’s what the API tokens are for. You create one named “vscode” specifically for VS Code, for example, then you can use it in your NGINX configuration.
Both:
proxy_set_header Authorization “Bearer oh.vscode....”;
and
proxy_set_header X-Openhab-Token “oh.vscode....”;
proxy_set_header Authorization “”;
will work, but in the second case, make sure to remove the original Authorization header that your client sent with the NGINX username & password.
(in fact proxy_set_header Authorization “Basic base64(oh.vscode....:)”; will work too).
Hi, just found this thread and was able to connect VS Code to my OH3 instance.
Can the rest api with VS Code also be used for rules (UI defined rules that is)? (at the moment the OH plugin only shows items and things)
No we are currently only working with items and things on the api side in the extension.
How would you like to use the rules part of the api in vscode?
Just to get an impression of what would be needed.
Hi Jerome,
Was wondering if its possible, and thinking that if you have access to items and things already, it would be great to have access to rules so that you can use VS Code for rule coding instead of the UI (as was/is possible when you use the files approach).
Not really a big deal though as I am working 90% (besides maps etc.) with the UI for now.
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.