The first request (or batch of requests) I send from a WCF-Custom adapter using the wsHttpBinding (also tried basicHttp) does not include the Authorization Header.
Request 1 Headers
POST https://axis2service.com/HttpSoap12Endpoint/ HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8
Host: axis2service.com
Content-Length: 556
Expect: 100-continue
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
The service returns a 401 to which I respond with the below.
Request 2 Headers
POST https://axis2service.com/HttpSoap12Endpoint/ HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8
Authorization: Basic XXXXXX
Host: axis2service.com
Content-Length: 556
Expect: 100-continue
Accept-Encoding: gzip, deflate
To which the axis2 on apache service responds with a 504 and Connection: close
This seems to be a known issue, how can I make request 1 include the Authorization header every time?
Note: The request 1 headers only get sent on the first request after a Host Instance restart. All subsequent requests from the adapter use the request 2 headers therefore bypassing the handshake stage.
Related
I am testing the here.com location REST API. I have setup REST oAuth credentials in the developer portal and have successfully requested an oAuth token via Postman. When I try to use the token in the fuel prices API, I receive the error:
"These credentials do not authorize access"
oAuth POST request:
Authorization: OAuth oauth_consumer_key="wD7h-u8jE03c0jRu2m4XBQ",oauth_signature_method="HMAC-SHA256",oauth_timestamp="1600812281",oauth_nonce="npygZT9FJ9f",oauth_version="1.0",oauth_signature="fM6AsYnp9jKHlY6ESyKwUwqIHQik4ad6spUeiWAh2ag%3D"
User-Agent: PostmanRuntime/7.26.5
Accept: */*
Cache-Control: no-cache
Postman-Token: 169bc9d1-5ef6-46e6-aab8-d0d11d048d15
Host: account.api.here.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 29
Request Body
Response Headers
Date: Tue, 22 Sep 2020 22:04:42 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 911
Connection: keep-alive
Pragma: no-cache
X-Request-ID: REQ-b62ce9c9-eddd-4c03-8e67-186a56c031b1
Cache-Control: no-store
X-Frame-Options: DENY
X-Response-Time: 53
X-Correlation-ID: e0c4b375-8fed-4b70-be56-2d78c6f37e18
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'self'
X-Permitted-Cross-Domain-Policies: master-only
Response Body
{"access_token":"eyJhbGciOiJSUzUxMiIsImN0eSI6IkpXVCIsImlzcyI6IkhFUkUiLCJhaWQiOiJaVjhwbGFFWDdRekd2VUNXbUdGbiIsImlhdCI6MTYwMDgxMjI4MiwiZXhwIjoxNjAwODk4NjgyLCJraWQiOiJqMSJ9.ZXlKaGJHY2lPaUprYVhJaUxDSmxibU1pT2lKQk1qVTJRMEpETFVoVE5URXlJbjAuLk8tRDdJQm9Mdzk5b1dxejJ1Vmx0Y1EuSmlYUmMwV0N6cVFUbVFicmhNaDNONkFENVJ6YWVMenFfdWpOWVZlekgyQ2dvbERLcFFEcUNrODFlMWFoMmlZZXZXZzFHNVhDZUtsZEc0WXhwX0pSU2lPaUkxUUNMRWZhakFscEFHQjdta0JLdjktbXllXzlqeDFGbzM2T0tUaDRuNXdxWEZVbnhtMkRYOHRQYjVZZUZBLl9qUlE0NU9PTmd3ZHpwY1c4cUxJck5hRmhYcTVLM1hzMHZzYl85MTFtVVU.R62C1fZVxt29r0VPA9jYVdWRbqO5lFH0yNtomCSxAnpTaHf4ed215u7o21RnwEjy-Dl2vgCAP8Oc4xNN4uoi2ImzwRtdtDU8y3wqOYHakRXyuP5PdvKejjpB1MAmw8TYVQkTfrfsgG972wo2g_0jx3VzmcOXJSl8wHU5y3rdEgNG-vDvV1wlJwQDX6ZKc2FLSzk1yEv9NSsAYur21PrnBfMImaenvGzEh1J747HmUfrHOPr-wRPvTQE4GNiOf4hWKXJrnPwpg85S_S8EZgGqlRVfNQ4V2g_7LfH1ZjFxiZrd8oZFPbnAI1ihDSBqaTy04HXotXsyp92YzDhVHwDavw","token_type":"bearer","expires_in":86399}
Get request to fuel REST API
GET https://fuel-v2.cc.ls.api.here.com/fuel/stations.json?prox=36.0029435,%20-78.9059841&fueltype=1
Request Headers
Authorization: Bearer eyJhbGciOiJSUzUxMiIsImN0eSI6IkpXVCIsImlzcyI6IkhFUkUiLCJhaWQiOiJaVjhwbGFFWDdRekd2VUNXbUdGbiIsImlhdCI6MTYwMDgxMjI4MiwiZXhwIjoxNjAwODk4NjgyLCJraWQiOiJqMSJ9.ZXlKaGJHY2lPaUprYVhJaUxDSmxibU1pT2lKQk1qVTJRMEpETFVoVE5URXlJbjAuLk8tRDdJQm9Mdzk5b1dxejJ1Vmx0Y1EuSmlYUmMwV0N6cVFUbVFicmhNaDNONkFENVJ6YWVMenFfdWpOWVZlekgyQ2dvbERLcFFEcUNrODFlMWFoMmlZZXZXZzFHNVhDZUtsZEc0WXhwX0pSU2lPaUkxUUNMRWZhakFscEFHQjdta0JLdjktbXllXzlqeDFGbzM2T0tUaDRuNXdxWEZVbnhtMkRYOHRQYjVZZUZBLl9qUlE0NU9PTmd3ZHpwY1c4cUxJck5hRmhYcTVLM1hzMHZzYl85MTFtVVU.R62C1fZVxt29r0VPA9jYVdWRbqO5lFH0yNtomCSxAnpTaHf4ed215u7o21RnwEjy-Dl2vgCAP8Oc4xNN4uoi2ImzwRtdtDU8y3wqOYHakRXyuP5PdvKejjpB1MAmw8TYVQkTfrfsgG972wo2g_0jx3VzmcOXJSl8wHU5y3rdEgNG-vDvV1wlJwQDX6ZKc2FLSzk1yEv9NSsAYur21PrnBfMImaenvGzEh1J747HmUfrHOPr-wRPvTQE4GNiOf4hWKXJrnPwpg85S_S8EZgGqlRVfNQ4V2g_7LfH1ZjFxiZrd8oZFPbnAI1ihDSBqaTy04HXotXsyp92YzDhVHwDavw
User-Agent: PostmanRuntime/7.26.5
Accept: */*
Cache-Control: no-cache
Postman-Token: d5d3944f-4c5c-44ef-8eb4-0202a4d669c0
Host: fuel-v2.cc.ls.api.here.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Response Headers
Content-Encoding: gzip
Content-Type: application/json
Date: Tue, 22 Sep 2020 22:11:15 GMT
Server: nginx-clojure
Vary: Accept-Encoding,Origin
X-HERE-RESPONSE-TIME: 0
Content-Length: 99
Connection: keep-alive
Response Body
{"Type":"Forbidden","Message":["These credentials do not authorize access"]}
Unfortunately, currently the Freemium plan doesn't have an access to Connected vehicle services https://developer.here.com/documentation#cvs
On https://developer.here.com/documentation/fuel-prices/dev_guide/topics/credentials.html you can see:
There are two kinds of credentials:
Development credentials - these credentials are for evaluation and
development. To obtain your development credentials, contact your
customer/sales representative and sign the appropriate evaluation
agreements.
Production credentials - these credentials are for commercial
deployment. To obtain your commercial credentials, sign the
appropriate commercial agreements. You must have completed all
testing, be ready for deployment and have signed a commercial
agreement before you apply for production credentials.
You can also read this Knowledge Base What other HERE Location Services limits apply to my Freemium or Pro plan? - there the information about Connected vehicle services will be added later.
I'm trying to create a user using the SaonarQube API (version 6.2 or up).
I have setup a SoapUI project that contains a few test scripts. One of them is login in and creating a user. this one returns a 401 whe the user creation call is done.
The login is used for other calls as well and proves to work. Except for the create user call. The account used to login to SoarQube is member of the System Administror groups.
Below is the raw request.
POST http://localhost:9000/api/users/create HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 47
Host: localhost:9000
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
Cookie: JWT-SESSION=eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiJBV0ExaGFtX2hnNWdHUWtNNVRHSiIsInN1YiI6ImFkbWluIiwiaWF0IjoxNTEyNzI2NDQwLCJleHAiOjE1MTI5ODU2NDAsImxhc3RSZWZyZXNoVGltZSI6MTUxMjcyNjQ0MDM4MywieHNyZlRva2VuIjoicHRwcXRlYmtzYTR2MTlhaTk3anV0bnVlZW8ifQ.waHqOsMJ9P6FyIOUWuVODl5QcW-IJp10G6oUAvy1DWk; XSRF-TOKEN=ptpqtebksa4v19ai97jutnueeo
Cookie2: $Version=1
login=user01&name=name01&password=%21P%40ssw0rd
Below is the raw resoonse
HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Content-Length: 0
Date: Fri, 08 Dec 2017 09:47:20 GMT
Any suggestions are welcome.
BTW: I can create the user using the same values using the UI so there is no issue with he user information, at least it seams so.
Update 1:
Added raw request with querystring parameters
POST http://localhost:9000/api/users/create?login=user01&name=name01&password=%21P%40ssw0rd HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
Host: localhost:9000
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
Cookie: JWT-SESSION=eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiJBV0JHZkVGY0h3bW5UZ0V5QklJNyIsInN1YiI6ImFkbWluIiwiaWF0IjoxNTEzMDExMDM2LCJleHAiOjE1MTMyNzAyMzYsImxhc3RSZWZyZXNoVGltZSI6MTUxMzAxMTAzNjQyNCwieHNyZlRva2VuIjoibmIzdmlpcjAyZmZ1ODJnMzNtdW1hYWdkN3QifQ.ur8eZkW1CwNinx4tInFsbkGLQTHQ6yFjheRfup8Z4fQ; XSRF-TOKEN=nb3viir02ffu82g33mumaagd7t
Cookie2: $Version=1
It's not possible to use the generated cookie by a web request in a console request (it could be considered as an attack).
You need either to :
Specify a user token (recommended way)
Specify a login/password
I need to configure Burp Suite to intercept data between web browser and proxy server. The proxy server requires a basic authentication (Username & Password) while connecting for the first time in each session. I have tried the 'Redirect to host' option in Burp Suite(Entered the proxy server address and port in the fields):
Proxy >> Options >> Proxy Listeners >> Request Handling
But I can't see an option to use the authentication that is required while connecting to this proxy server.
While accessing google.com, the request headers are:
GET / HTTP/1.1
Host: google.com
User-Agent: Mozilla/5.0 (X11; Linux i686) KHTML/4.13.3 (like Gecko) Konqueror/4.13
Accept: text/html, text/*;q=0.9, image/jpeg;q=0.9, image/png;q=0.9, image/*;q=0.9, */*;q=0.8
Accept-Encoding: gzip, deflate, x-gzip, x-deflate
Accept-Charset: utf-8,*;q=0.5
Accept-Language: en-US,en;q=0.9
Connection: close
And the response is:
HTTP/1.1 400 Bad Request
Server: squid/3.3.8
Mime-Version: 1.0
Date: Thu, 10 Mar 2016 15:14:12 GMT
Content-Type: text/html
Content-Length: 3163
X-Squid-Error: ERR_INVALID_URL 0
Vary: Accept-Language
Content-Language: en
X-Cache: MISS from proxy.abc.in
X-Cache-Lookup: NONE from proxy.abc.in:3343
Via: 1.1 proxy.abc.in (squid/3.3.8)
Connection: close
you were on the right track, just at the wrong place. You need to setup an upstream proxy at:
Options>>Connections>>Upstream proxy
There you can also setup the authentication
Options>>Connections>>Platform authentication
Here you can create different auth configurations, which will be done if the server requests it.
What is a common approach in authenticating of user session for websocket connection?
As I understand websocket message contains data only with no headers. Thus authorization cookie is not available to server backend. How should application distinguish messages from different clients?
Which websocket server are you using?
if your webserver and websocketserver are the same, you could send the sessionid via websocket and force-disconnect any client that does not send a valid sessionid in his first message.
if your websocketserver parses the HTTP headers sent in the HTTP upgrade request properly, it may also save any cookie. this is what a request of my firefox (version 35) looks like:
GET /whiteboard HTTP/1.1
Host: *:*
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Sec-WebSocket-Version: 13
Origin: *
Sec-WebSocket-Protocol: whiteboard
Sec-WebSocket-Key: iGPS0jjbNiGAYrIyC/YCzw==
Cookie: PHPSESSID=9fli75enklqmv1a30hbdmg1461
Connection: keep-alive, Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
as you see, the phpsessionid is transmitted fine. check the documentation of your websocketserver if it parses the HTTP headers. remember that cookies will not be sent if the websocket's domain differs from the webserver's domain.
I've a DotnetOpenAuth authorization server which works great on my localhost. However after publishing it my refresh access token request is blocked.
The request for a accesstoken, with success
POST https://myurl/identity/oauth/token HTTP/1.1
Authorization: Basic dsjSDLFJKSKLJesww
Content-Type: application/x-www-form-urlencoded; charset=utf-8
User-Agent: DotNetOpenAuth.Core/4.2.1.13026
Host: myhost
Cache-Control: no-store,no-cache
Pragma: no-cache
Content-Length: 86
Expect: 100-continue
Connection: Keep-Alive
username=theusername&password=fancypassword&scope=somescope&grant_type=password
The refresh request:
POST https://myurl/identity/oauth/token HTTP/1.1
Authorization: Basic dsjSDLFJKSKLJesww
Content-Type: application/x-www-form-urlencoded; charset=utf-8
User-Agent: DotNetOpenAuth.Core/4.2.1.13026
Host: myhost
Cache-Control: no-store,no-cache
Pragma: no-cache
Content-Length: 272
Expect: 100-continue
refresh_token=_ttH%21IAAAAGiYhlufAaXURH5P2oDOnPYgJx7YhoR33isvZkPPvlyUgQAAAAHoBYyDMLhq1qwGHHH2uGrLoHZli77XHbCnSFJSKLFJ3kl2j3klj2kljKFSJKLSJKL#$k3ljfsklfjl2
And the response:
Technical Information (for support personnel)
Error Code: 403 Forbidden. The server denied the specified Uniform
Resource Locator (URL). Contact the server administrator. (12202)
Any help, guidelines, pointers in any direction, would be very much appriciated!
I changed the url/username/password/scope/base64/refreshtoken for this example.
Their seems to be a setting in the TMG Forefront - Authentication Delegation which blocked the request.
Method used by Forefront TMG to authenticate to the published Web
server:
No delegation, and the client cannot authenticate directly
No delegation, but client may authenticate directly
It was set to option 1 after changing it to 2 the request is no longer blocked!