Short version:
If the function wwv_flow_custom_auth_std.is_session_valid (or apex_custom_auth_std.is_session_valid) returns TRUE, is it possible that the session is expired but still alive? If so, how can you check if a session is expired?
Long version:
I have created a single-sign-on system for our Oracle APEX applications, roughly based on this tutorial:
http://www.oracle.com/technology/oramag/oracle/09-may/o39security.html
The only difference is that my master SSO login is in Perl, rather than another APEX app. It sets an SSO cookie, and the app can check if it's valid with a database procedure.
I have noticed that when I arrive in the morning, the whole system doesn't work. I reload a page from the APEX app, it then sends me to the SSO page because the session was expired, I logon, and get redirected back to my original APEX app page. This usually works except first thing in the morning. It seems the APEX session is expired. In that case it seems to find the session, but then refuse to use it, and sends me back to the login page.
I've tried my best to trace the problem. The "wwv_flow_custom_auth_std.is_session_valid" function returns true, so I'm assuming the session is valid. But nothing works until I remove the APEX session cookie. Then I can log back in easily.
Anybody knows if there is another call that would tell me if the session is expired or not?
Thanks
You can set the Maximum Session length in seconds under the application security attributes page.
Apex states the following:
"The session duration may be superseded by the operation of the job that runs every eight hours which deletes sessions older than 12 hours."
You could use the view apex_040100.APEX_WORKSPACE_SESSIONS to determine if a session is valid based on its existance or creation time. eg: session_created - systdate > 12Hours.
You should also use the "On session timeout direct to this URL" attribute.
This solution would require privileged access but you can query the wwv_flow_sessions$ view in your apex schema for any session that matches your username. If none exists, your session has timed out. This view also gives you a field 'idle_timeout_on' that will tell when your session is scheduled to time out.
Related
In my application I updated only the Shiro library, from shiro-all-1.2.6.jar to shiro-all-1.3.0.jar. I did not change any other libraries, nor configuration files, other than the build path to refer to the new Shiro library.
The logs show that the users do actually get logged in, but the server side is not accessible anymore, right after shiro login.
Trying to figure out what changed between 1.2.6.and 1.3.0, and what settings do I need to change, to make the application work as before.
Thanks a bunch!
-Alina.
After more digging, I found out that the connection to the server was lost due to the fact that in the process, a new session is created, as the initial session is lost.
When calling Session session = currentUser.getSession();, I expect to get the same session associated with the logged-in user. Instead, a new session is created, because the old one does not persist.
Again, this is happening with Shiro 1.3.0, but not with Shiro 1.2.6.
I am wondering if there is a setting that we need to apply, for the session to persist, and not get lost. I wonder if the session times out instantly.
I have user login feature in my application. I used Scala Play Framework as controller. I create sessions using withSession('userId'->userIDValue) for different users. My application has a feature that there will be one super user and super user can delete user. Now what happens is that if super user deletes a user but that user is logged in then that user's session is running till cookie of browser expires. Play Framework is stateless; is there any way to solve this problem?
On incoming requests, I think you need to verify that a user is still active on the Play side, and not just only trust the session.
If that's an expensive operation, e.g., you have to make a database call to verify if a user is still active, then maybe you can use the Play Cache API. If you only have one Play server instance, then it should be pretty easy -- you can just set something in the cache when the super user deletes a user, and have the cache item expiration be longer than your cookie expiration. If you have multiple Play server instances, then it's tricker. :)
Our API returns a user auth code which has a session expiry (30 mins of inactivity). So, if we make an api call using the auth token it renews the session to 30 mins from the time of the call.
After 30 mins of inactivity the api returns an error saying that the token has expired. At this point we should request a new auth token.
However, the obvious way to do this (show the user the log in screen and get them to log in again) will mean cutting the user off in the middle of some functions in the app.
For instance, we have various view controllers with options and inputs which aggregate and submit one whole API call at the end of the process. If the session expires on the server whilst the user is filling out these inputs and views then they will be logged out when the API call is made, and they will lose their progress in these views.
There are two possible work arounds for this:
We set timers in the app ourself to make sure the user is logged out after 30 mins inactivity in the app. This means that they won't get logged out during a set of inputs, however this poses the issues that: the server API may still expire even though we are running our own timer. This won't work therefore.
We poll every 10 seconds or so to the server to ask if the API auth token is still valid. This will eat battery, data and all sorts and just isn't a reasonable way to do something like this.
Does anyone have any ideas?
Thanks
Tom
From your description, it sounds like a classic failed transaction problem. Just in case you are not familiar with transaction processing, "Nuts and Bolts of Transaction Processing" is a primer on the topic.
If you have the ability to modify the back end system, you will want to ensure an ACID backend.
This could mean building up data on the client and not send the data to the server until you have a complete transaction. That way, if the session times out, the client still has all the data needed to complete the transaction. (leverage atomicity)
This could mean having a transaction token. As a new session is created the client could send the server the transaction token and the state of the transaction is restored within the new session. (leverage durability)
To me both of these options are better than wiping out the existing transaction and forcing the user to start over again.
Hope that helps.
Our application is using Symfony 2.0 and MongoDB with FOSUserBundle for user management.
Client wants to prevent login with the same username from different device at the same time in their application.
Our idea is to invalidate/delete all other sessions for the same user when the successful login occurs.
The problem is, that we cannot save session in DB, because Mongo Session handler was added later in the version 2.1.
The only solution we come up with is to iterate over the session files saved in file-system and check if the username of the user is saved in that file. If that is true, we just delete the file and login session on other locations are terminated. Of course we have to check that we don't delete the current session also.
Does anyone have a better idea how the problem could be solved?
If not, are there any hidden traps that we should know about?
You could add an IP address column to the user entity that stores the current user's IP upon login. On each page load (via an event listener), you could check the IP stored in the DB against the IP of the person requesting the page. If the IP in the DB doesn't match the current user's IP (someone logged in from another location), log them out.
To take it a step further, via ajax, you could make a call to the server every X seconds that performs the same type of check, and do a redirect to log the user out if the ajax request returns a bad match.
I've developing my first iOS app which allows users to login to an account on our website, and view / add / edit / delete records in a database.
I've written a basic app which handles the process like this;
App starts running.
Each view controller calls a checkAuth method from within the viewWillAppear method. This method gets the username and password stored within the app, sends them to the server as GET variables in a dataWithContentsOfURL request. The resulting JSON is then checked, if the response is a failure, then an alert dialog is shown, and the user is taken to a different tab (I'm using a tab bar controller) where they are prompted to enter their login details.
Using this method, every time a different view controller takes over (each scene in my storyboard file), the auth method is called. This seems a little wasteful. Is there a better way of ensuring a users login credentials are correct?
Thanks.
Storing the username and password in the app is bad practice. If modifying the back end is within your control, it would be better to authenticate to the back end, and get back a token that is only good for that device.
From here, you pass the token along with each request, and if the back end determines you have logged out then it should return an error message. This way, the authentication would be checked on an ad-hoc basis and only when sending a request.
I see no reason to do it every time a view loads, unless there is a business requirement for this.
Why don't you use a "communication management" singleton for this? It would handle all the tasks of authenticating and communicating with the server, and each one of your controllers talks to it without directly interacting with the server.
You could have an inactivity session timeout: via NSTimer.
Set a session timeout marker on successful login (e.g. login time plus 10 minutes).
As the user uses the app keep updating the stored session timeout time to the current time plus 10 minutes (invalidate the timer and create a new one).
When app exits or goes into background invalidate the timer.
Have the timer call a logout method when the timer times out.
Oh, and don't store username/password in the app. Use the keychain to store them encrypted (if necessary to keep them local). I suggest only the username should be stored locally.