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.
Related
I'm facing an issue in AEM6.1 were the users have an invalid login-token (due to having an expired session). They make a request to AEM author which then has an error because they are basically an anonymous user attempting to view a page. The access problem results in a 404. The ACS error page tries to handle it, but the error page like everything else on author is not readable to an anonymous user. So it has a Java exception, and the user is left with a white screen of death
The login-token cookies in the browser have no expiration. They appear to be configured to stick around until the session is closed by the users. I would like to set expiration on the login-token cookies.
I've research around but do not see how this is done. The aemstuff site http://www.aemstuff.com/#article964 points to "Apache Jackrabbit Oak TokenConfiguration" But this was already set to 43200000, and further changes do not effect the login cookie expiration as far as I can see.
My question for SO is; is there a way to set the login-token expiration on the cookie? It seems like a bug with "Apache Jackrabbit Oak TokenConfiguration" or is it?
Create Apache Jackrabbit Oak TokenConfiguration as a config node.
In case others face similar problems, here some of the things I learned about this
login-token expiration can be configured as suggested by disha. It is used on the backend only. I think its very typical for browser session cookies to not have an the expiry set.
The WSOD issue experienced may have been helped by adjusting this session timeout slightly less than the IDP timeout
I think it's very important to use Java 8 with AEM6.1 and perhaps other versions as well. When we upgraded from AEM6, Java 7 remained our running version. Possibly the SAML SSO uses Java 8 things. After going to Java 8, users never had the WSOD again.
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. :)
I have been asked to use ember for front end and java rest services as the backend. I am trying to figure out how to manage session for a particular user.
i know there are couple of options like storing in the local store, cookie but they are error prone as some users might disable those features. I want to know what is the preferred approach in normal enterprise apps.
Mine app is simple 15 page app. i need to capture user, and some profile details.
Session are usually more of server side part. You have to just make sure whether the provided session is available or not for every transformed route and request. There is a library which takes care of authentication and authorization in ember https://github.com/simplabs/ember-simple-auth.
How are browsers implementing requests for Application Cache manifest files and is it different from how other files are requested?
I ask because I'm seeing behavior I wouldn't expect when using Windows/NTLM authentication in IIS 7. The situation is that I have a site with a manifest file defined. With anonymous authentication, everything works as expected -- the site loads and is available offline.
When I disable anonymous and enable Windows authentication, the site will load fine after authenticating, but I will see an error in the console (in Chrome or on an iPad 2) that says the manifest file could not be fetched.
On the iPad, the error is that the Application Cache file could not be fetched. In Chrome, the specific error is "Application Cache Error event: Manifest fetch failed (401)." I can see the 401 response code in the web server logs in both instances.
Why this behavior seems unexpected is requests for all other resources (CSS, JavaScript, images) all work as expected. Also, I can browse to my .appcache file and it loads.
Can anyone explain what's going on?
Has anyone else run into this and found a solution?
Not sure if this is still relevant, but I'm also having this problem.
As my site makes AJAX requests, once the page has loaded I am asked for credentials for the request to take place. Once this has happened, running applicationCache.update() causes the application cache to update correctly.
Therefore, as a work around, perhaps try making an AJAX request to something so that the user is prompted for credentials, then call applicationCache.update().
i have also run into this problem. Exactly as you described, but i am using basic auth on Apache. I am going to try making the the mainfest file public.
I know its an old question but i had the exact same problem which led me here.
my setup is:
server - IIS8
authentication - windows
anonymous authentication - enabled (did this so i could get my dynamic manifest to be fetched regardless of authentication, i had to then decorate all other controllers with [Authorize])
With the above setup the application would cache properly however when loading from the cache, if there was an update to the manifest certain sections were not fetching (such as authorized content) because the user was not "logged in" and hence making the whole update even fail.
My solution was to add in an ajax call to an authorized resource, this way when the user was online they would be prompted to log in meaning that the next time the cache was updated they were authorized again.
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.