Closed JulianFeinauer closed 2 years ago
At least for the plain WS version, I do believe this is due to the fact that browsers can't provide credentials using the Authorization
header, and so we don't have credentials to validate. For OAuth2 token we provide the (undocumented) token
query parameter. But we have nothing for API keys (username/password).
I implemented support for API keys + username authentications using query parameters for all drogue services. So you now have four ways of authenticating :
Authentication: Bearer
header, providing a valid Oauth TokenAuthentication: Basic
header, providing a username and an API Tokentoken
, providing a valid Oauth Tokenusername
and api_key
, providing a username and an API Token. Using more than one of the above will result in an Invalid Request
.
Here is an example with the websocket endpoint (but it should work with all other drogue endpoint requiring authentication)
[drogue-cloud] websocat -v "ws://websocket-integration.192.168.49.2.nip.io:30004/example-app?username=admin&api_key=$KEY"
[INFO websocat::lints] Auto-inserting the line mode
[INFO websocat::stdio_threaded_peer] get_stdio_peer (threaded)
[INFO websocat::ws_client_peer] get_ws_client_peer
[INFO websocat::ws_client_peer] Connected to ws
I found out that the websocket integration does not work when used from a browser although it works e.g. with websocat. Short analysis from @ctron indicates that this is related to no auth headers being sent (username / pw are provided as part of the host). Similar issues arise when using MQTT over Websocket. I was unable to get it work with MQTT Explorer and via paho js from inside a browser.