I'm currently using http sessions but am wondering if it would be better for me to switch to native shiro sessions. This post is a followup to my posting on problems with WebRememberMeManager, but I'm starting a new thread since it pertains to a different question.
Here are some of my objectives, and I'd like to know if http or native sessions makes better sense: 1. Be able to indicate which users on the system are currently online with somewhat decent reliability. 2. Be able to know the date/time that a user last logged into the system 3. Be able to know the date/time that a user last logged off the system (or the session ended) Also, we are currently having to run two UI interfaces to our application at the same time: A: The currently publicly available release is built with wicket: a: Wicket relies heavily on http sessions b: Markup with data is generated on the server and served as html c: Data is submitted to the server with standard form submits/POSTs B: We're working on a newly redesigned version of the application, with the following goals: a: Static http servers will serve html, css, js, and images b: The application has one single main static HTML page and a JS library that is the same for everyone c: This single page application is simply a shell that knows how to load JSON data and build features and content accordingly d: JS in the main shell requests a JSON document from a REST service that details which features are available to the user based on their roles/privs e: JS in the main shell then assembles the proper UI features based on this description of a user's privileges f: All application data is loaded via service layer api calls using JSON g: JS in the frontend generates HTML markup based on JSON data and simple static HTML templates Right now we are heavily using the rememberMe cookie. But with this new design I'm thinking that we'll have to pass login credentials or some sort of login token with every REST request. At this time, everything is on the same host in a single Jetty server. This means static resources (html, css, js, img), wicket pages, the RESTful service API, and so forth will all receive the rememberMe cookie, and therefore work properly. But we want to move the service API to separate servers, which means that rememberMe features would no longer work. We will need to support both the current interface and the new UI concurrently for some time. It's working now because it is all on the same host, but as soon as we split things up, we'll have problems. Also, by sharing the same host, both of our separate interfaces show the same data since the same hibernate cache is being used. That's a separate issue, but something to consider. Any thoughts or suggestions on the best way to utilize Shiro to support this scenario would be appreciated. Could I use the rememberMe features to essentially build a login token that would be sent with each REST request to the service layer? Thanks, Tauren
