I want to add basic auth header in the autobahn client tool. How can I achieve that?
Current request
GET / HTTP/1.1
User-Agent: AutobahnPython/0.5.2
Host: 10.35.34.172:9000
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Key: 1U4OeBs60qkmk1V/8voLOw==
Sec-WebSocket-Version: 8
Request I need:
GET / HTTP/1.1
User-Agent: AutobahnPython/0.5.2
Host: 10.35.34.172:9000
Authorization: Basic TXlMb2NhdGlvbkFwcDpNeUxvY2F0aW9uQXBwMTIz
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Key: 1U4OeBs60qkmk1V/8voLOw==
Sec-WebSocket-Version: 8
Note: I don't want autobahn server to authenticate the client.
My scenario is autobahn client --> my server --> autobahn server.
My server will take care of extracting the authorization header and then invoke the autobahn server.
I have implemented options to send custom HTTP headers for both AutobahnPython client and server. You need to use the latest AutobahnPython on GitHub (master branch).
A client can send headers by providing a headers keyword argument during construction of the WebSocketClientFactory or set headers via setSessionParameters.
A server can send headers similar to client, and additionally specify headers when returning from onConnect.
Here is a complete example.
Disclaimer: I am original author of Autobahn and work for Tavendo.
Related
I'm using gssapi/Kerberos authentication in my web application, and I want single sign on via the browser.
The problem is, Firefox sends an initial request to the server with no authentication, and receives a 401. But it includes a keep-alive header:
Connection: keep-alive
If the server respects this keep-alive request, and returns a WWW-Authenticate header, then Firefox behaves correctly and sends the local user's Kerberos credentials, and all is well.
But, if the server doesn't keep the connection alive, Firefox will not send another request with the credentials, even though the response has the WWW-Authenticate header.
This is a problem because I'm using Django, and Django doesn't support the keep-alive protocol.
Is there a way to make Firefox negotiate without the keep-alive? In the RFC that defines the Negotiate extension, there's nothing about requiring that the same connection be re-used.
Alternatively, is there a way to make Firefofx preemptively send the credentials on the first request? This is explicitly allowed in the RFC.
That header is HTTP 1.0, wake up, fast-forward 15 years and your problems will go away. Firefox works very well with SPNEGO.
We're writing Windows app and we also have backend server. And we want to implement Google Login. So the Windows app asks the user, it receives the JWT token and passes it to our server. I the token, there are 2 keys: aud and azp. On our other platoforms (iOS, Android), the azp is the OAuth Client ID of the application from Google Cloud Console and aud is OAuth Client ID for our server. But on Windows, they are both same. On other platform, this is handled by libraries provided by Google, but on Windows, we're using low-level HTTP. But we can't find a way to specify the aud. How can we do it?
EDIT: I found out about audience:server:client_id:... in scope, but it doesn't work for me either. It gives me Error: invalid_scope.
This is the request (using HTTPie):
http -v https://accounts.google.com/o/oauth2/auth client_id==windows-ios-app-client_id.apps.googleusercontent.com redirect_uri==my.bundle.id: response_type==code 'scope==audience:server:client_id:server-client-id.apps.googleusercontent.com'
GET /o/oauth2/auth?client_id=windows-ios-app-client_id.apps.googleusercontent.com&redirect_uri=my.bundle.id%3A&response_type=code&scope=audience%3Aserver%3Aclient_id%3Aserver-client-id.apps.googleusercontent.com HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Host: accounts.google.com
User-Agent: HTTPie/0.9.2
I think we should provide this scope while you request for token. This is probably automatically done if we use Google/Sign-In library, provided that we set the server client id.
[GIDSignIn sharedInstance].serverClientID = #"YOUR_SERVER_CLIENT_ID_HERE"
By the way, If any am looking for a way to implement the same using AppAuth. I did not find any solution yet.
Send the web client id as a parameter audience=WEB_CLIENT_ID when requesting token endpoint.
I am using ESP8266-Websocket, aws-sdk-arduino(cleaned branch) and pubsubclient to try to comunicate with aws iot mqtt service using websockets.
My question is about the first connection request. I am using this browser app as reference https://github.com/awslabs/aws-iot-examples and the sign code from aws-sdk-arduino (that works fine calling the aws iot restful api)
My request was this (after connect to the endpoint at 443 port):
GET wss://ENDPOINT.iot.us-west-2.amazonaws.com/mqtt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AWSKEY%2F20160318%2Fus-west-2%2Fiotdevicegateway%2Faws4_request&X-Amz-Date=20160318T183246Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=a1f0d7b58983f9dff7e3bf6cab062db3243ebafc990803a018c6a23433891404 HTTP/1.1
host: ENDPOINT.iot.us-west-2.amazonaws.com
Connection: Upgrade
Upgrade: websocket
Origin: file://
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: D2alJOyUkBlR+8yhv2UBLg==
Sec-WebSocket-Protocol: mqtt
but I keep getting
HTTP/1.1 403 Forbidden
content-type: application/json
content-length: 241
date: Fri, 18 Mar 2016 18:34:57 GMT
x-amzn-RequestId: f2edfe83-1bbc-4481-97e0-39ccfc4d1c2f
connection: Keep-Alive
x-amzn-ErrorType: ForbiddenException:
am i missing some request header parameter? is there anyway to get a better feedback from x-amzn-ErrorType: ForbiddenException? am i messing up in the sign process? (even though it works for rest call)
Yeah, I've finally got response status 101 switching protocols \o/
when you are building the request, it must be:
GET /mqtt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AWSKEY%2F20160318%2Fus-west-2%2Fiotdevicegateway%2Faws4_request&X-Amz-Date=20160318T183246Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=a1f0d7b58983f9dff7e3bf6cab062db3243ebafc990803a018c6a23433891404 HTTP/1.1
instead of
GET wss://ENDPOINT.iot.us-west-2.amazonaws.com/mqtt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AWSKEY%2F20160318%2Fus-west-2%2Fiotdevicegateway%2Faws4_request&X-Amz-Date=20160318T183246Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=a1f0d7b58983f9dff7e3bf6cab062db3243ebafc990803a018c6a23433891404 HTTP/1.1
the js example that I was following was using the full path. When I got the request built by chrome (throught developer tools) the path was full as well. Just after use firebug I got the real request that browser was sending to the server (with short path).
now I can continue to try the solution (mqtt over websockets at esp8266) :-) if it works, I will share the code ;-)
I am debugging my website. When it has an error, the full text form of the HTTP request that caused the error is logged. I want to be able to replay these HTTP requests to help debugging the error.
For instance, I have this in my log now:
POST /ipn/handler.ashx?inst=272&msgType=result HTTP/1.0
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Host: mysite.com
Content-Length: 28
User-Agent: AGENT/1.0 (UserAgent)
region=website&compName=ACTL
I want a way to make this exact request again on my local test machine (with changed Host attribute). What is the best way to do this?
You could use telnet to talk to your web server and type the exact requests.
You could also use libcurl (& curl) to make a program which is an HTTP client.
And many scripting languages (Python, Ruby, Perl, Ocaml, ...) also have HTTP client libraries (sometimes above Curl).
I found the apache xfire has add one head parameter in its post header:
POST /testservice/services/TestService1.1 HTTP/1.1
SOAPAction: "testAPI" Content-Type: text/xml; charset=UTF-8
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; XFire Client +http://xfire.codehaus.org)
Host: 192.168.10.111:9082
Expect: 100-continue
Will this Expect: 100-continue make the roundtrip call between the xfire client and its endpoint server a little bit waste because it will use one more handshake for the origin server to return the "willing to accept request"?
This just my guess.
Vance
I know this is old question but as I was just researching the subject, here is my answer. You don't really need to use "Expect: 100-continue" and it indeed does introduce extra roundtrip. The purpose of this header is to indicate to the server that you want your request to be validated before posting the data. This also means that if it is set, you are committed to waiting (within your own timeout period - not indefinitely!) for server response (either 100 or HTTP failure) before sending your form or data. Although it seems like extra expense, it is meant to improve performance in failure cases, by allowing the server to make you know not to send the data (since the request has failed).
If the header is not set by the client, this means you are not awaiting for 100 code from the server and should send your data in the request body. Here is relevant standard: http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html (jump to section 8.2.3).
Hint for .NET 4 users: this header can be disabled using static property "Expect100Continue"
Hint for libcurl users: there was a bug in old version 7.15 when disabling this header wasn't working; fixed in newer versions (more here: http://curl.haxx.se/mail/lib-2006-08/0061.html)