I have a public Apex app and I need a specific page to open in a different session. Not use the same session as the rest of the application.
Basically, I have in Chrome
Tab1 : Page A which requires authentication
Tab2 : Page B which is public
I need both pages to run in two different sessions.
At Page B level, I set "Rejoin Sessions" to Disabled
Now when I run the application, Page B opens in a new tab with a new session as expected, however, it kills the session of Page A and I'm redirected to login.
I'm using an Authentication Scheme with custumized session sharing:
Does anyone know how to solve that please ?
Thanks
Cheers,
The reason it kills your session from page A is because, on the client side, sessions are implemented using cookies. Both page A and page B are trying to use the same session cookie, with different session IDs, so whichever one writes to it more recently kills the other one.
If you view your cookies using your browser's F12 developer tools, you should see one like this:
Name Value Domain Path
ORA_WWV_APP_115305 ORA_WWV_FMN08hWNhlkjRDOIU_y yoursite.com /pls/apex (etc)
This is the session cookie for APP ID 115305, and the browser will send it along with every HTTP request to yoursite.com/pls/apex. Apex uses the Value to verify that you are allowed to have access to the session specified by the ID in your URL. If you modify either the cookie or the URL's session ID, your session is lost and Apex creates a new one for you.
So the Name + Domain + Path forms a sort of unique key here. You can only have one session for each unique Name + Domain + Path cookie.
I think the easiest solution here is to put your public page B in a separate Apex App. That way it'll have its own session cookie with a different Name.
(This is how the Oracle App Builder, which is also an Apex App, can have a separate session going at the same time without killing your app's session. Its cookies use a Name like ORA_WWV_USER_9872)
The alternatives are to use a different Domain or Path for page B, but that's trickier.
It looks like you've set up a custom Authentication Scheme, so I think your cookie would look like:
Name Value Domain Path
SESSIONCOOKIE ORA_WWV_FMN08hWNhlkjRDOIU_y yoursite.com / (etc)
But you're still using the same Authentication Scheme (and the same cookie) for both page A and page B, so they can't have separate sessions. This would be an instance where it might be nice if Oracle supported using a separate Authentication Scheme for each page, but they don't. This is what separate apps are for.
Related
In implementation of Login, I want to make sure if a user is already logged in one tab of the browser and opens the same web site in another tab, he gets redirected to homepage rather than the log in page. It's an ideal scenario as it happens in all the web site. I am achieving the same by storing logged in unique user token in local storage. Is it the best way to achieve it? Kindly guide! is it safe? If not how to go about it?
Just consider everything on the client as tainted or possibly manipulated.
So basically you should always check on the server side if the client has a valid session and only then deliver the homepage to it.
I would use a cookie set by the server side - just a random id bound to the actual client session on the server.
So the client could mess with that, but would have a hard time to guess another (also random) session id.
The cookie should be cleared by the server if the user logs out.
Then I would check on every call if he has a valid session id and if not directly send him to the login page by a redirect. Additionally you could then send him from the login page to the homepage whenever he is already logged in.
What are the different ways of maintaining session in a browser?
Consider a scenario;
I am browsing a secure site in Firefox and the browser crashes. Now when I open the browser again and I do Restore tabs, my previous session is restored back ? Is that handled automatically by the browser OR is it code-based ?
Also can we control session based on tab close vs window close, etc
Is there any connect between maintaining the session at server vs having the same at client side?
What are the different ways of maintaining session in a browser?
Different ways to maintaining sessions are :-
Cookies ( Most Standard way )
Url Rewriting
Html Forms hidden fields
Consider a scenario; I am browsing a secure site in Firefox and the
browser crashes. Now when I open the browser again and I do Restore
tabs, my previous session is restored back ? Is that handled
automatically by the browser OR is it code-based ?
It is handled by browser automatically if it was cookie based, other wise you will manage that.
Also can we control session based on tab close vs window close, etc
On server you can control session just by time, mean when it will invalid, but if you want to do something that will invalid session when close tab then according to me you can bind on close event in javascript and then delete the cookie that was used to manage the session, PHPSESSION ( in php's case )
Is there any connect between maintaining the session at server vs
having the same at client side?
Yup :)
when you create a session actually you are sending a cookie.
Think you are coding in php, and you create a session, now what happens is: a file will be created on the server (file is the default way to handle session in php but you can also change that) and a unique id will also create on server that will represent that session, think you create a session so a file will created with name sjflsj3lrh324l2hjlskdjfl3hl.session and a unique id will also created ex:- sjflsj3lrh324l2hjlskdjfl3hl.
Now when you store anything in session you actually are storing that in this file, and when you will send response to browser, you will also send a cookie on browser and the cookie value will be this id. So next time when you reopen that web, browser will first check if there was any cookie received from this domain before. If yes, then send that with request, and then on server php will check if request contains any cookie with it. If so, then it will check if that name file exists, and if exists mean there was a session. It will then open that file and all variables values that was saved in it will be restored in php variables.
i'm trying to create a web app with back and front end separated, so there is two project here. The reason is there is a plan in the future to create mobile version as well, so i made it decoupled.
Just FYI the back are created with PHP using laravel4 and barryvdh CORS
and the front end are created purely with angularjs and bootstrap.
The current situation is that i create a rest API in my back end app to do login, auth, and logout.and in the front end i have 2 pages, which is login and index page.
Login page are composed of username, password input field and submit button,
when user click submit button, it will call the login rest API from the back end and i expect it would persist cookie to the front end page if login success, but it doesn't (because of cross origin policy, i've research as much).
The question is, is there any way to set sessions across domains now it is 2014, where any article i found are from 2012 older. If it's not possible, what's the easiest way to persist session across domain besides OAUTH2 and openID (because their learning curve are just too steep, the application i'm creating are just small app)
Thanks for your assistance.
what I have done so far to work with cross-domain sessions is to create a "passport" service on a another domain and validate & handle the session from the there.
For example...
domain1.com has webserver1
domain2.com has webserver2
passport.com has webserver3
Whenever I connect either to domain1.com or domain2.com I'm including a line at the very top of the script index checking on passport.com/check.php whether there's a browser session already initialized under the name of "PASSPORT", if so, I finish the checking on passport.com and let the script on domain1.com or domain2.com to do their stuff.
In case the browser session wasn't initialized, the check.php will redirect the index via header() to the login.php page. This will validate against LDAP and if binding the user is OK then the browser session is initialized with the name of "PASSPORT" and including all the fields I need furthermore to validate the user and its accesses. Ref back to the index once is done.
When the user goes from domain1.com to domain2.com (or the other way around) the script included at the top of each index will check the session again all the time, taking the user to the login script or letting him access the required site.
As additional checking you can create the session and add variables such as "valid until", "access level", etc.
Hope this helps and if you need further clarification let me know.
Best,
Emiliano.
I'm working with an old ASP.NET application which has lots of lousy code.
I have been mostly a winform developer and my knowledge of webforms is still limited.
However looking at code the way the developer tried to pass information to other pages sound invalid to me.
Here is a typical way he passes info from one page to other page:
Response.Redirect("ABC.aspx?SessionID=08F7DCF3D6984EC984F6580A4EC7E9C2&CID=" _
& e.Item.Cells(iColClientID).Text & "", True)
Then on other pages he uses Request.QueryString to get the data back:
Request.QueryString
My question is why in the world he needs to also pass a Hardcoded SessionID=08F7DCF3D6984EC984F6580A4EC7E9C2 in the query string.
Web.config shows :
<sessionState mode="InProc" cookieless="false" timeout="30"/>
So if session is using cookies why send session id?
To me code is written by an amature developer. Please provide your feedback.
Unless he uses the SessionID parameter for something else -some other obscure logic in there that relies on it being present in the QueryString-, there's no reason to put a SessionID in the query string at all. With or without cookies enabled how to get the SessionID should be transparent to you and it suffices to do:
var sessionID = Session.SessionID;
Some relevant documentation from MSDN regarding cookieless sessions (which is not the case here according to the Web.config you showed):
ASP.NET maintains cookieless session state by automatically inserting
a unique session ID into the page's URL. For example, the following
URL has been modified by ASP.NET to include the unique session ID
lit3py55t21z5v55vlm25s55:
http://www.example.com/(S(lit3py55t21z5v55vlm25s55))/orderform.aspx
When ASP.NET sends a page to the browser, it modifies any links in the
page that use an application-relative path by embedding a session ID
value in the links. (Links with absolute paths are not modified.)
Session state is maintained as long as the user clicks links that have
been modified in this manner. However, if the client rewrites a URL
that is supplied by the application, ASP.NET may not be able to
resolve the session ID and associate the request with an existing
session. In that case, a new session is started for the request.
I'm maintaining a system built in ASP.
The login process is in SSL. Meaning, when the user clicks on "Login", his user name and password are sent securely to the server.
The login process produces a Session object, which is the ID of the now logged-in user.
After finishing the login process, the page redirects the browser to a non secure page. This page tries to access the ID Session object.
Until last week, this worked fine. Our system was running on IIS6.0, and the non-secure page could access this Secure ID Session object.
However, after switching over to IIS7.5, this inevitable security hole was closed(or so I assume). The non-secure page cannot access the Secure ID Session object anymore.
Access to the object is done simply like this:
string ID = Session(SESSION_USER_ID)
just to check things out, I tried access a non-secure Session object from the Secure login pages - this failed as well.
Is there any way to access a Secure Session object from a non-secure page?
BTW, I've probably mistaken with some of the terms here, but I think the scenario is more or less clear. Please tell me if this is not the case.
I've come across this problem before, I ended up getting around it by, when changing into or out of SSL, calling a function that would write the session variables to cookies, and then read back from the cookies into the SSL session variables.