I've been using Advanced Rest client to test my REST api. Earlier Advanced Rest client used to open as a new tab in chrome. So I could Login into my application in one browser tab and in a new tab I could open Advanced Rest client, call my api's.. test it. Everything was ok.
But now after the new update Advanced Rest client has become a separate app, I can no longer open it in a new tab. So now I when I call my rest api's, I'm getting No session.
How do I add session in the new update of Rest client?
You will need to install this extension (ARC cookie exchange): https://chrome.google.com/webstore/detail/arc-cookie-exchange/apcedakaoficjlofohhcmkkljehnmebp
and enable the Use XHR toggle in the Advanced rest client. It should then work.
It depends on a session type. If this is a cookies based session the app is already supports cookies. They are saved in local database (as user agents would do) and automatically added to the request when the domain and path of the cookie matches the request URL. (domain and path matching algorithm is defined in the spec: https://www.rfc-editor.org/rfc/rfc6265#section-5.1.3).
The app will not accept cookies set in regular Chrome session since Chrome apps do not have access to the Chrome's cookie storage. There's simply no API for this. So session registration must be done in app - not the browser. So if the session is set up after form submission you need to create the request that will send form data as regular form would do and then use the app normally.
Related
In a spring security application i am navigating to the login page and entering my credentials and getting logged in.Now again if i open a new tab in the same browser and navigate to the login url it shows me the login page.If I enter another users credentials and login my previous Jsession ID(ie: the one created in the previous tab) is getting overridden with the new jsession id.Upon refreshing the previous tab the session is overridden.
I want to implement that if a user is logged in already in the application, upon navigating to the url again in another tab on the same browser the homepage of the application should open.
Please advise as how I can accomplish that?
Since the server uses the cookie to map to the current session, you'd have to control how the browser sends cookies. Every time a request is sent to a website from a new tab, most browsers will send all the cookies it has for that domain. Since your server received the same session cookie, it will treat this request as being in the same session. There's no way it can tell the difference.
Therefore, as far as cookie-based web sessions go at least, you probably won't be able to force the creation of a new session upon opening a new tab.
Using the OktaSignIn widget, I see I can get res.session.token. Can I use this (or some other attribute) in another app -- with the APIKey -- and validate that this is a valid session?
We just want a simple to use auth system and don't want to set up OpenAuth...
Can't seem to find any APIs that do what I need.. but could have missed it of course...
Edit. Basically... our front end uses the OktaSignInWidget... then we want to use this in a Bearer token our API Services layer can validate.
Thanks!
Looks like this will work...
/api/v1/sessions/me
Get id from this.
{"id":"102wtHeHhr4Q4q4rh2Fjy6pGA","userId":"00u9uwkfyfiz3Y7uk0h7",
Then... this can be passed and using the API key...Issue a GET to...
/api/v1/sessions/102wtHeHhr4Q4q4rh2Fjy6pGA
Returns...
Session...
The call to /api/v1/sessions requires the API key -- which is fine.
As you mentioned, you can use the session id to see if the session is still valid on the Okta server by:
Exchanging sessionToken for okta session
After redirecting back to your app, calling /api/v1/sessions/me to get the sessionId
Using that sessionId in the request to /api/v1/sessions/id with an apiToken to see if it's still valid
This will exist as long as the user has not logged out of Okta, but the browser state might be different - for example, the Okta session cookie will normally be deleted when the user's browser closes, while the session might still exist on the server.
Alternatively, to check if the browser session still exists, you could make the validation check on the client side by making the request to /api/v1/sessions/me - the one gotcha is to make sure that CORS is enabled for both the domains your apps are running on so they have permissions to make this request to Okta.
The above methods work, but it does sound like what you should be looking into is Okta's API Access Management (OAuth2) - it was designed for this type of flow (passing Bearer tokens to your API services layer).
I am writing an application that requires authentication using the OAuth2 Protocol. I have managed to use the Web Server App authentication mechanism and it's working quite well, the only problem is that I am handling the redirect_url within the program itself and I don't want the browser to make the request in a new tab.
If it were possible, the ideal solution would be that google server would send the request to me directly, or that it would open and close the browser tab/window.
Perhaps this approach is not the most appropriate, if so please let me know how to do this better.
Fair warning, haven't used oAuth like this but I do have an idea:
Can't you just open the oauth request in a pop-up with window.open()?
Getting the parent of the popup is then as easy using window.opener.
After OAuth validation you could refresh the parent with:
window.opener.location.reload();
You could then simply use window.close() to close the popup.
This way no new tabs will be opened and your application will remain the active tab.
Yes its possible I am actually doing just that in my .Net application using a web browser control. You have tagged this Google Oauth so I am assuming you are doing this with Googles auth servers. I suspect you are using one of Googles client libraries which are built to open it in a new browser window by default. The Google .Net client library for example is designed to do this.
The trick may require that instead of using a web credentials you use native or other type credentials which do not require a redirect URI. These credentials are normally used for installed applications but they can be used for web. It may be possible to do it with web credentials but I think its going to depend a little on what you are doing exactly.
Google Oauth2 flow:
The first step in the flow is creating the URL for the user to authenticate. This is a webpage there is nothing you can do to change that. So your application will need to be able to display a webpage to the user.
https://accounts.google.com/o/oauth2/auth?client_id={clientid}.apps.googleusercontent.com&redirect_uri=urn:ietf:wg:oauth:2.0:oob&scope=https://www.googleapis.com/auth/analytics.readonly&response_type=code
by supplying urn:ietf:wg:oauth:2.0:oob you are basically telling the auth server to just return the code to where you sent it from.
The code is returned to you and you will need to swap it. This call is a HTTP POST.
https://accounts.google.com/o/oauth2/token
code=4/X9lG6uWd8-MMJPElWggHZRzyFKtp.QubAT_P-GEwePvB8fYmgkJzntDnaiAI&client_id={ClientId}.apps.googleusercontent.com&client_secret={ClientSecret}&redirect_uri=urn:ietf:wg:oauth:2.0:oob&grant_type=authorization_code
response
{
"access_token" : "ya29.1.AADtN_VSBMC2Ga2lhxsTKjVQ_ROco8VbD6h01aj4PcKHLm6qvHbNtn-_BIzXMw",
"token_type" : "Bearer",
"expires_in" : 3600,
"refresh_token" : "1/J-3zPA8XR1o_cXebV9sDKn_f5MTqaFhKFxH-3PUPiJ4"
}
Now you have a refresh toke and an access token. you can refresh your access token using another HTTP POst call.
https://accounts.google.com/o/oauth2/token
client_id={ClientId}.apps.googleusercontent.com&client_secret={ClientSecret}&refresh_token=1/ffYmfI0sjR54Ft9oupubLzrJhD1hZS5tWQcyAvNECCA&grant_type=refresh_token
Response
{
"access_token" : "ya29.1.AADtN_XK16As2ZHlScqOxGtntIlevNcasMSPwGiE3pe5ANZfrmJTcsI3ZtAjv4sDrPDRnQ",
"token_type" : "Bearer",
"expires_in" : 3600
}
So as long as you can embed the auth URL into your application you can fetch it yourself. You don't need the redirect URI. my tutorial on google 3 legged oauth2
Since you're already using non-portable xdg-open, you probably can use another external tool (xdotool) and emulate users keystrokes with it:
xdotool search --onlyvisible --class "Chrome" windowfocus key 'ctrl+w'
This will send ctrl+w (close tab) to visible chrome instance
Keep in mind there may be more than one browser window open.
I have a Spring 3 MVC app and part of the app requires a redirect to a 3rd party payment site and that payment site redirects back to my app after it's done. The problem is that Spring seems to create a new session instead of using the old one and erases all the data previously stored in the session. This creates massive problems for my app and I'm wondering if there is a way to preserve the session after external redirect?
Also, cookie are enabled on my browser and I indeed verified that the jsessionid value in the cookie changes after the redirect, indicating a new session overwriting the old one.
Can you provide the following info:
After coming back from the 3rd party site, does your app use a different domain/sub domain from what it uses before redirecting to the 3rd party site?
Is there a possibility that your session timeout value is so low that the session expires by the time the user returns to your app?
Does your app use frames having onunload events that invalidate the session?
I just thought about writing a GWT app that just works as a client for a RESTful web service. The web service requires HTTP basic authentication for each call.
Since the client is not 'connected' with the server over a session, I have to remember the authentication credentials on the client side. I could do this within the GWT application, but with this, the client has to log in after every reload, which is not very beautiful. I also don't think it's a good idea to write this information to cookies, since everyone could read them.
So, who knows what I am looking for? :-)
Browsers save the username/password information for a given server/port/domain. So if the client has to login once (at least via the browser standard BASIC http dialog) it's preserved over the reloads.
I don't know if you can do that. Maybe forcing the user to navigate to a page inside the domain (or realm) and then using GWT...