I'm simulating an HTTPS process with Google App Engine's URL fetch API. The process has 2 steps: first, a GET request will return an URL with URL-encoded session information and a cookie; and second, a POST with some payload to the returned URL.
I have used Firebug to capture the headers of the 2 requests, e.g User-agent, Keep-alive, Connection, Cookie. I used these same headers in my code (the cookie value is updated according to the response). Testing on my computer is successful but the code always fails at the POST step on Google's server. On my development box, the remote .NET app website replies to the POST request with a 200-OK with the information that I want, but on Google side, the remote .NET app website also give a 200-OK response but with a "Session timeout" message (which I don't want). So what have I missed?
Are you connectiong to the GAE applictation through appspot.com domain or a custom domain? SSL is supported only on appspot.com, so maybe this the reason?
Related
i'm trying to integrate java application with azure ad .
i have registered an app in azure and added redirect url's , after successful login , it was redirected to my java application where i am fetching authorization code using msal library.
Getting the below exception
com.microsoft.aad.msal4j.MsalServiceException: AADSTS500112: The reply address
'http://testUrl' does not match the reply address 'https://testUrl
the only difference i see in the above url's is http and https, even though i mentioned https in both redirect url in the app registrations as well as redirect_uri in the microsoft login url.
btw, it was working with my local environment, not working when i hosted it on the server .
We had the same issue after it was deployed in production environment. The reason the https became http is since I was in a load-balanced environment, the outside URL differed from the inside URL (The load balancers off-loaded the SSL processing). When the http request from azure reached our web filter, the httpRequest.getRequestURL().toString() get the http instead of https. What we did is, ask devops team to add a header in httprequest with the original url sent to load balancer, and in our code, we extract the http header instead of the http request itself.
Specifically, change
String currentUri = httpRequest.getRequestURL().toString();
to
String currentUri = httpRequest.req.getHeader(HEADER_PROXY_URL);
The HEADER_PROXY_URL is the header name that devops inject the original url.
According to my research, the redirect URL for web apps and services must begin with the scheme https. If you want to use the scheme http, you just can use http:\\localhost. For more details, please refer to https://learn.microsoft.com/en-us/azure/active-directory/develop/azure-ad-endpoint-comparison#restrictions-on-redirect-urls
As I understand, in authorization code flow we need to get authorization code and use it to get token after. We can get this code only when user confirms specified access. After that browser redirects us to redirect_uri and response will contain authorization code as parameter. So, the question: is it possible to get this authorization code without browser or any self made UI? Can we get it in application after correct request to, for example https://mysite.tuz/authorize ?
As you are using authorization code flow, the client requires a user agent (i.e browser or mobile app) to get the authorization code from the authorization server.
The whole purpose of using authorization code is that it can be passed via the user's web browser (user agent) instead of passing the access tokens directly via the web browser (user agent) which is not desired. Using authorization code,the Client then can directly retrieve an Access Token from the authorization server.
So the user agent is required to get the authorization code and act as an intermediary between client and authorization server.
If you do not require a browser then authorization code flow may not the correct choice. OAuth 2.0 supports several different grants i.e ways of retrieving an Access Token. Deciding which one is suited for your case depends mostly on your Client's type.
This might help you in deciding which flow to use
https://auth0.com/docs/api-auth/which-oauth-flow-to-use
You should use client credentials to obtain token without browser or any client. But if you need to use user credentials to get access token and id token of the user without browser or mobile app you need to implement you own client which will do the necessary logic for you and fetch the token for you. I already did it in java for the testing purpose. I don't know why you need to do it but you can implement your own client in almost any programming language . But in case you will decide to go this way you have to handle lot of things.
I expect your authorization server requires Proof-Key for Code
Exchange (PKCE) - so first of all before you start to communication
with server you have to create code verifier and code challenge
(google can help you with that :) in java it is quite simple)
Then you should start communication with server sending get request to url which ends with 'auth' you should send query params as: response_type (which is 'authorization_code' in your case), redirect_uri, client_id, code_verifier, code_challenge, scope, code_challenge_method (probably 'S256')
Then you receive I think two redirects from server so it is better to have some client in java which will automatically call those redirects. I used apache http client for my implementation. It has lot of features.
After successful redirect server will return login page to your client. It depends on authorization server but in this page you should put the data as username and password and submit the page. I have simply parsed the returned page and get the url for user authentication from it and simply make post request to that url with user credentials data sent in encoded form entity. In apache http client you will have all cookies from previous communication set (until you close the client) since apache http client automatically set all cookies returned in previous communication from server.
After make authentication request server will send you two redirects and you can store those redirects int http client context which you will provide for http client when you call authentication url.
In the last redirect there will be query parameter sent be server named "CODE" this is really important for you since you will use it to get token from the server
And finally you have to make one last post request to authorization server with url ended as token. So make a post request with GRANT_TYPE, REDIRECT_URI, CODE (you received in previous redirect), CLIENT_ID, CODE_VERIFIER (you have generated at the beginning);
Then authorization server will send you token and that's all
I am not able to capture POST request payload which is sent by chrome browser for forms.
I have tried Browser mob proxy but it only captures in har file the request url, response code but not request payload.
I want to validate the request payload via java or selenium or any automation script and not via manual verification.
Any suggestion will be helpful.
As browser mob only captures request url and response status but not payload data. I stopped using browsermob.
I used Fiddler instead which worked perfectly for me. The only problem was unlike browser mob I had to install Fiddler application in my system for which I had to approached to my superiors for permissions for fiddler installation.
I have a GWT appilcation in which the client makes a request to another domain.
I wrote the request using RequestBuilder in GWT.
On executing the code, I get an error in my browser :
No 'Access-Control-Allow-Origin' header is present on the requested resource.
So I google and I found that the domain to which I am making the request should add this header in the response that it sends. Now I dont't have control over the other domain's server, so I can't do any modification there.
My question is, can I intercept the response and the Access-Control-Allow-Origin header to the response that is being sent by the other domain's server at my server, before I send it to my client?
I tried using Filters but the Filter doesn't get called for responses coming from another domain.
Is this possible to do, am I missing something or is it just not possible?
Vivek's answer that cross domain requests aren't allowed by the browser is true, except for the CORS mechanism, whereby newer browsers that support it can try in a cross origin way to servers that also support it.
However, unless that remote server support it itself, there is nothing you can do. If I server my app from A, and want to connect to B, only B can authorize that. If A were allowed to permit my app to connect to B via some filter or servlet, then I could write an app that makes calls to gmail or facebook or twitter and read/write your settings and personal data at those other urls.
So instead, it is the cross origin server that you are contacting that must approve the connection with the header you mentioned. In lieu of that, you can still use your own server as a proxy for the cross origin server.
Cross-domain requests are forbidden by web browsers as per the same origin security policy. These restrictions are limited to browser based applications and hence you can definitely use your own server application as a filter between the GWT based client side application and the external server.
My question is similiar to How should I be implementing the HTTP POST Protocol Binding for SAML WebSSO Profile?, but I don't see exact answer that I needed. This is my case. I already implemented Service Provider for WEB SSO SP-initiated POST redirecting and my IDP is active directory and STS is ADFS2.0. After user log on, I need to send another AuthnRequest to ADFS2.0 without user agent interaction. Is it possible with HTTP POST? Or to send over HTTP POST, user agent interaction must needed. I set isPassive=true. I try to implement using Java.
Ok you could build an authentication request and send it to ADFS2 using any HTTP client (i.e. http://www.innovation.ch/java/HTTPClient/ works for me). But ADFS2 will always reponse you with the Login Form. The problem is that in the request you were missing the cookies that ADFS2 is using for tracking your session (SamlSession cookie).
Hope it helps,
Luis
ps: why do you need to send another authn request?