Develop Reference

what is current subject in Shiro?

I'm new to Shiro and got confused about the current subject concept:
Subject subject = SecurityUtils.getSubject(); // gets the current subject
subject.login(...); // do login
subject.logout(); // do logout
In my application I need to run work from different users concurrently, thus multiple users(subjects) co-exist concurrently, new users login and old users logout on the fly: clients sends work with [username, password] to server, the server do credential check by Shiro with the given [username, password], if [username, password] not exist in database, reject the work, if exist, login and dispatch the work to be processed, in the meanwhile other clients sends their work and login, my question is in a later time when the work for a user is done and I need to logout out the user, how do I get the subject for it?

SecurityUtils.getSubject() returns the subject bound to the current thread (typical web app pattern), the source of the session is typically from information in a Http Session or Http Request. (Shiro is NOT bound to the Servlet API, it is just a really common model). So in the context of your application, the request might be just some method call containing the current User/Subject (not sure how your application makes this association or authenticates them, but that is a different question). This means you may not need to use SecurityUtils.getSubject().
Once you have a Subject and if you want to use SecurityUtils.getSubject() elsewhere in your code, you could wrap the call in a Callable: https://shiro.apache.org/subject.html#automatic-association (this is basically what Shiro's Servlet module does)

need to store Caches an Cookies up to ending a session

How can we keep caches and cookies in native app up to completing a session (example booking tickets) in Retrofit(or other rest calls).
Ex. while booking tickets online, we will keep session up to last step of the process. I need to keep my session in a native app up to the last step of a similar process.

managing sessions in rmi application [duplicate]

This question already has an answer here:
How a server can make a session with a client in RMI
(1 answer)
Closed 5 years ago.
I'm writing an RMI application which uses swings on the client side. The user has to first login with his email and password. After his login a new JFrame is opened and based upon his email id from first ui, I should fetch data from database in the second ui.
I am new to this thing and I want to know how I can maintain sessions so that username is propagated to all JFrames. I read an article about using system properties as shown to store username:
System.setProperty("application.userName", myUserName);
I want to know whether using system properties to store email is good practice or can i maintain session in a more better way?

Have the login method return a new remote object that is dedicated to that session. In fact it is that session. When the client releases the stub the session will be DGC'd, or you could provide a logout() method in the session object along with all the other methods your session needs.

Session Should not expire

I have 2 application,
1 as A application and
2 as B application.
Now from A , I am navigating to b application, there I will spend some time. And In B I have a log off button, if user clicks on that, it should come back to application A, with session intact.
I am using J2EE and Weblogic server, Here servers of a and b are also different.
Can any one please help me, I need to complete this work by today eveining.
Thank you for your help in advance.

Here is one way of doing it
Assume that a user is on application A with valid session.
When you click a link (or post some data) to go on application B, pass some token in query string. (This token may encrypted (username+password+salt)).
Application B receives the query string data, decrypts it and authenticates the user.
When user clicks log off in application B, the log off handler in application B (it could be a servlet/JSP/Controller/Action etc), does s response.sendRedirect() to the application A.
which will still have its session intact (provided session has not timed out i.e. the time user spent on application B is less than the session timeout of application A).

Session hijacking: Pros/Cons of a filter that suppresses Session IDs

I am trying to address session fixation/hijacking/sidejacking on an ATG/JBoss/Tomcat site. It seems that by far, the most commons recommendations are:
Grant a new session to the user when they log in. This prevents the attacker from being able to predict the session ID of the victim. I tried this approach first, but I fear it may not work in my case
Use a servlet filter to invalidate the session anytime a session ID (SID) is passed in the URL. The filter additionally prevents url rewriting for creating links w/ SIDs
What are the pros and cons of #2? Some that I've thought of:
Pros:
This seems like a broader protection than #1: #1 protects against malicious URLs being passed to the victim, #2 protects against any means of acquiring SIDs (insecure wireless networks, access to the machine, etc) - you can't just pass the SID you want to use a request parameter!
Cons:
Session management will be shot for users without cookies enabled.
Normal users will be logged out if they click a link w/ jsessionid specified, though I don't believe there will be any legitmate links like that in the system, due to the behavior of the filter.

2 is to stop Session Fixation.
You also need to take CSRF aka "Session Riding" into consideration. Here are methods of preventing CSRF.
Finaly don't forget the most overlooked OWASP, OWASP A9 - Insufficient Transport Layer Protection. This means that your Session ID must be transmitted over HTTPS at all times. If you don't then someone can use Firesheep to grab the account.

You could store a variable in the session that contains the user's IP, user agent, etc. or a hash of them and check it every request so that if it is hijacked the hijackers would have to fake those.
Not perfect but it helps.