I need a solution such as Make.com or Pipedrive.com that will allow me to recreate a POST http request to loginto the site and return the cookies. Currently, with Make.com I can successfully return a single cookie. However, I need to be able to return all the cookies with this request as I am able to do so with Postman..
I am looking to be able to return all cookies with the login credentials for a website. I am able to do this request successfully with PostMan, however, I need a cloud based solution like Make.com to do this request?
Related
We have a third party service that implemented single-sign-on on some route to it’s web-app.
In order to use this single-sign-on, we provided with a POST API, and we need to pass on that route some credentials- including an organization secret that we got from him (yes, we need to pass it in query params), and the user’s email address.
In order to not to expose credentials over the browser, we tried to mimic that request by creating our own backend endpoint, and return the same result as their enpoint (kind of a proxy) with redirection (status 307 with Location header) cause there API returns plain HTML.
It seems like when client send a post request with redirection he can’t add the authorization header (JWT) required by our backend to operate (backend return Authorization required). the request is been done to our server and the result is redirection to another server.
How can we bypass it? Or maybe we can secure it with different approach?
I know that the header is usually been removed for a good reason, who knows where I can be redirected to?
but can't I tell him somehow that I trust the redirection?
We tried to use phantom-form only to use from submit post. We tried to make our endpoint to be GET and making the redirection other way (react-router) but I think that natively js does not allow to attach Authorization header.
I thought it would be a common pattern, but I didn't find someone that talks about it exactly, since we are trying to query our backend and not some external redirection API.
I wish to implement an Auth handler for requests that handles authentication with an OAuth Authorization server to allow the following:
import requests
requests.get(url, auth=KeycloakAuth())
What I've done so far is to apply a response hook when KeycloakAuth is called, so that when the client redirects the caller to Keycloak, the hook will see the Keycloak login page, post the credentials to Keycloak and get redirected back to the client.
However, this does not work for a POST, as requests makes a POST to Keycloak's login page instead of a GET due to the redirect. Keycloak doesn't return the login form in response to a POST and this fails.
I considered checking for the redirect in the response hook so that I can modify the redirect to do a GET to Keycloak instead, but it seems like requests' implementation of redirects bypasses all the hooks.
After poking into this a bit more, I believe this may be the wrong question to ask.
I was seeking a solution where, regardless of the original HTTP method used on the client (GET, POST, HEAD, etc), the library would automatically login to Keycloak, and then "replay" the original request to the client and make it effectively transparent to the user of the library.
However, this can't possibly work with OAuth 2.0 without further state management on either the part of the library or the client, due to the redirecting.
Suppose the original request was a POST, with some data. After finding that the user is not logged in, the User-Agent will be redirected to the Authorization Server for authentication.
This means that the original request's POST data will be lost, removing the opportunity for any replay, upon the User-Agent being redirected back to the client after authentication.
With some state management, the POST data could be stored for replay - it doesn't make sense to store the data on the server side since the data could be arbitrarily large, which leaves us with the user of the library to do the state management.
However, that amount of state management should probably not belong in a library, since the library will have to handle lots of cases to guarantee only-once delivery of the request, for example, which would be expected by the user of the requests library.
As such, this Auth handler is probably not something we can implement in a library.
I authenticate in Postman by sending a POST request to an api endpoint (https) with my credentials included. The response sets two cookies.
Set-Cookie →atlassian.xsrf.token=AGH6-ZEXS-8CED-D3BW|96bac852b72xxx42042593f13axxxxe7f3ff1d5f|lout;path=/;Secure
Set-Cookie →JSESSIONID=8C53xxx0xxxx46B4A5201A68C098604DF08;path=/;Secure;HttpOnly
I click the 'Cookies' button in Postman and see that these two cookies are saved. When I now send a GET request to a secured page, I get authenticated and receive the expected response.
However, I need to do this programatically, so I try to set the cookies manually by adding a header to the request, using the same values I got in the original response.
Cookie: atlassian.xsrf.token=AGH6-ZEXS-8CED-D3BW|5xxxxxxxxba42582fb230ac7d7416e81204|lout;JSESSIONID=7AFxxxxxxxx27A461A01C193C57D
I also delete the cookies saved in Postman.
Now, my request gets redirected to a login-screen, as I apparently did not get authenticated.
What is the difference between my first and second GET request? How can I make sure the request is authenticated correctly?
Sorry for the late reply.
In your first GET, postman will send the JSESSIONID to your server. You're already authenticated so the request will be obviously accepted.
But for the second one, you don't provide the JSESSIONID cookie and more important your JSESSIONID is not associated to a living Http Session.
I've written my own login app to protect my api following the oauth-login-app example.
I've implemented the web server flow and everything works great.
My question is: how should I handle an authentication failure at step 3? How do I tell he client app that the authentication failed? The user could either press the cancel button, or refuse permission or just enter the wrong details.
When you initiate OAuth 2.0 (dance) with
/authorize
the user-agent land on /login page (created/hosted by you),
post redirect.
enduser(user-agent) submits the username/password
to the page hosted by you. Here you collect the credentials and
submit to Apigee, and if authentication fails, send a HTTP 401
response. Now your application should be in position to re-render
the login page and with a flash "invalid credential".
Now coming to if user is authenticated but rejects the authorization request in
consent page, you should redirect to the "redirect_uri" provided
by client, with error code.
How do I tell he client app that the authentication failed?
The login app will redirect the control back to the application redirect URI - with added error code/description in the URL as hash parameters. In case of success the URL is appended with code or token.
You can do this redirect from your login app directly but I would suggest to make the redirect call first to an Apigee Proxy and let Apigee Proxy send the redirect back to app. Both in case of success and failure. In this way you will have the benefit of using Apigee analytics that helps your understand how many OAuths failed for what reason etc.
EDIT:
You can use the same GenerateAuthorizationCode proxy you have built for the success flow. When login fails or succeeds, in either case you need to pass that information to this proxy. Generally the login app and this proxy should share this information using a common session store. You can not pass this information just using a redirect parameter because that can be changed by the client user agent. When you redirect to the GenerateAuthorizationCode redirect proxy, do so by appending a random session ID in the URL. That id can be used by the GenerateAuthorizationCode proxy to look up the login status from the session store. Then you can either send back a redirect with error or a proper oauth code based on if the login was successful. An easy implementation of the session store can be done using a distributed caching resource in the apigee gateway. Login app can put/get the session using an internal API. While the proxy can use policies to retrieve the session information.
I am trying to implement SSO with a vendor, and they require I send a HTTP request. In this HTTP request, there is a custom header for username and password, which is where I pass in the u/p info. If the user is authenticated, then they send back an 'auth cookie'. I'm trying to understand a few things:
What exactly is this auth cookie? Is this a standard thing? or all it means is that its a cookie that has authentication information?
The HTTP request is sent to a domain which is different than mine. i.e., the script that sends the request is on a.com and the URL where I need to send the HTTP request is b.com. The vendor is saying that I am supposed to just 'send' the cookie they return in the response back to the user. This is not working, but I need to understand why - what will the domain of the cookie be? Will it be a.com or b.com? If its b.com, will that work, because the script that is actually making the call will be in a.com, and most browsers don't allow third-party domain cookie. Or is it failing because I am trying to write a cookie with a.com, where the cookie already has data for b.com?
Figured this out. The HTTP returned is just another custom header value, and not a cookie. So, we have to write our own cookie. However, obviously, the other domain doesn't recognise the cookie. So we actually build a reverse proxy in IIS, so that the domain a.com accesses the site through the proxy, called x.a.com, and never see b.com. So the cookie written is recognized by that domain.