In the previous blog "acegi security form-based authentication-debug debugging", we described a phenomenon that the previous page is retained every time a new browser is opened. For the previous example, either the current user information or the permission information is not available. This occurs. We have analyzed this in the previous blog, that is, there are already authenticated permission objects in securitycontext.
So, I want to re-run the userinfo. jsp page and re-authenticate it. What should I do? The only way is to stop the server; open server again; don't be so stupid. Someone will say, silly, run the login. jsp page. This is also a method. However, when the page is static for half a day and then refreshed, what do you think you should do as a programmer? What is the result?
Based on this condition, we will introduce you to httpSessionContextIntegrationFilter. This session filter has been introduced in the beginning, but it has never been used in two demos. Today, we will add this fiter in the acegi configuration file. Remember that this sessionfilter is before each filter, and the filter in the acegi configuration file has a sequence requirement. Do you think of it? If not, review acegi security Entry and add sessionfiter to the acegi configuration file in form authentication demo.
<bean id="filterChainProxy" class="org.acegisecurity.util.FilterChainProxy"> <property name ="filterInvocationDefinitionSource"> <value > PATTERN_TYPE_APACHE_ANT /**=httpSessionContextIntegrationFilter,authenticationProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor </value > </property > </bean > <bean id ="httpSessionContextIntegrationFilter" class="org.acegisecurity.context.HttpSessionContextIntegrationFilter" />
In addition, the acegi control process is as follows:
The purpose is to open another session browser or jump to the login page after the session expires. Run the following command after adding sessionfitler: 1. still running http: // localhost: 8080/acegitest2/userinfo. jsp 2. when the first operation occurs, the logon page is displayed. Use test/1 to log on without a permission. The "no permission" page is displayed. if you do not close this browser, open another browser and run http: // localhost: 8080/acegitest2/userinfo again. jsp what page does your browser display? Yes? Still like this?
If yes, the session is the same. We know that sessions are shared by default in IE8. Test Tool: IE9. Is IE8. 4. Close the browser, open a browser, and run http: // localhost: 8080/acegitest2/userinfo. jsp again. What page does your browser display? You will find that the same page is login. jsp in IE8 and IE9. 5. Thinking? The login page appears again for verification, which indicates different sessions. After the browser is closed, the session will be unavailable for IE8 and 9. We know that cookies are stored on the client, session is maintained on the server, and the browser is closed, but the client is closed and tomcat is not stopped? Does the server know that the browser is closed?
A series of interactions between the browser and the server are called a session.
- Where is the session stored?
Sessions are stored on the server and maintained by the server.
The session is created on the server, of course, the server.
- When will the session be created? Is it created when we access the url address?
Many people think that a session is automatically generated when a url is run. This is a lot of incorrect ideas. We can also understand this point of view, because at first we did not do it manually or did not involve session, it was natural to generate this point of view, in addition, most of us use a framework or visit other people's websites, and all of them will have a memory function.
In fact, the session is created through the java program: request. getSession (flag); does getSession not obtain the current session? How does it create a session? No create? In fact, this is an implicit creation. Let's explain this method, maybe at first glance, And I mistakenly think about it. Request. getSession (flag); why is there a parameter? What do you usually do without parameters? It may affect your program. If flag is set to false, if request. getSession (false) is set, the current session is returned. If no value is set, null is returned. If flag is set to true, if request. getSession (true) is set, the current session is returned. If no value is set, a session is created. We often use the request. getSession (); is this method equivalent to the above? Haha, unfortunately, it is equivalent to the method where the parameter is true. Are you shot? Haha, you see why the session is generated.
Someone must have stood up and refuted it. I just created a new helloworld. jsp. Without any java program, the jsp can still output the session. In jsp, <% out. println (session. getId () ;%> explains this phenomenon. Haha, this time you are again in the dark. We all know that jsp is finally compiled into a java program. In fact, jsp is a sevlet, so servlet certainly takes precedence over jsp pages. Dear user, check whether the request. getSession (); is similar in jsp compilation into a java program. In tomcat_home/work/Catalina/localhost/org/your project/org/apache/jsp/Corresponding java and class files in your jsp directory, try to open it, suddenly, I found that KAO really had this sentence: session = pageContext. getSession (); I will not explain pageContext. Is there a way to get cheated. In fact, they are good for us.
At this point, the person just stood up again and wondered again, but there was no jsp, just a <% out. println (session. getId (); %> statement. In fact, in jsp, the default situation will be: <% @ page session = "true" %>. If your jsp display is changed to: <% @ page session = "false" %>, then the bald jsp session will be null. Is there a way of getting cheated. In fact, people are really good for us.
- When will the session be destroyed? When will it be destroyed?
We learned when the session was created and when the session was destroyed? Just now, the acegi framework test demo closed the browser and the session was null, causing re-verification and entering the login page. That means closing the browser will destroy the session? Since session creation is determined by the program, session destruction is also determined by the program session. invalidate. So close the browser and the session becomes null, is it because session. invalidate () is called? The order cannot be reversed. If the browser is closed and session. invalidate () is called, the session becomes null. In turn, it will not work. Why do most people feel that the browser is closed, the session is null, and the session in the key acegidemo is also null ?? You need to understand the principle of the session.
- Session Technical Principles
When a browser accesses the server, the server first checks whether the client request contains the session ID. If yes, the server has opened a session space for the client and then searches for a specific session based on the ID; if no session exists, the server creates a session for the client and sends the session ID to the browser. In fact, the session uses cookies to save the sessionid, but in the cookie, it is not the sessionid, but the jsessionid. However, jsessionid is the value of sessionid. In this case, the cookie has a browser lifecycle. When the browser is closed, the cookie will disappear, and the jsessionid in the cookie will disappear. Therefore, the session on the server cannot be found. However, the session still exists on the server, but the client can no longer find the session. Therefore, when the browser is closed, it seems that the session is destroyed because most sessions are implemented based on the sessionid stored in cookies. however, the real session object is not destroyed on the server and will not be destroyed. Is it always occupying the memory?
Because the browser is closed and the session cannot be actually destroyed, the server has a session time mechanism. when the server detects that a session has exceeded the specified time from its last active period, the server will call the session. invalidate () to destroy. the default configuration time of tomcat is 30 minutes [tomcat6.0.37]. Of course, you can modify this time by yourself and directly use the web in your project. xml. So the session destruction is as follows: one is to call session. invalidate (); the other is session expiration; the other is to stop the server.
What if the cookie is disabled on the client? This uses another technology-URL rewriting. URL rewriting is followed by a jsessionid. There are two display Methods: http: // localhost: 8080/Project Name, jsessionid = *** another type is http: // localhost: 8080/project name? How to Implement jsessionid =? This uses the APIS provided by java. Respone. encodeURL ("Address") and response. encodeRedirectURL use response. sendRedirect (response. encodeRedirectURL) to redirect the application. The two methods can be used to determine that if the client disables cookies, jsessionid will be added after the url address; if the client supports cookies, the original url address will be added.
After learning about the session, it will be easy to talk about the common logout functions of the system in the next blog. If you have any findings or opinions on this part, you can test it on your own and communicate with each other in a timely manner.
