Tag Archives: cookie

Solution to cross domain sharing problem of session

Before discussing the cross domain sharing of session, we should first understand what session has done and has not done

    HTTP is stateless, that is to say, the server does not know who has visited it, but sometimes we need to keep this state. For example, if the user logs in every time, the user experience is really bad. Session solves this problem. It maintains the user login information on the server and generates a jsessionid for the customer The client will take this jsession ID with it the next time it visits the server, and the server will search the user information according to this ID. Of course, the disadvantages of session are also obvious. Session exists in the memory of the server. If there are too many sessions, the performance of the server will be affected. Because session is only in one server, when there are multiple servers, accessing other servers will definitely fail.

After making clear what session does and its defects, it is much easier to solve the problems existing in session. Let me briefly talk about five solutions

Session stickysession copy session centralized storage cookietoken

Session sticky: it means that requests from the same client will fall on the same server, because they will not fall on other servers, so cross domain problems will not occur. But the disadvantage of this scheme is very obvious, that is, no matter what algorithm is used, the user will decide which server the user’s request falls on, which may cause a single point of pressure, and if a server has problems, it may cause people in an area to be unable to access

Session replication: refers to the synchronization of session information between servers, that is, all session information is saved on each server. The disadvantages of doing so are also very obvious. As mentioned above, session is stored in memory, which will seriously affect the performance of the server. Of course, you can also store it in the database, but it will greatly affect the response speed. Another disadvantage is that when the traffic is too large, it will cause a lot of network overhead due to the problem of mutual synchronization

Session centralized storage: it refers to the centralized storage of sessions in a third-party server, which can be redis, database or other things. When you need to access it, go to this server. This also has some disadvantages. First of all, it is a single point problem. If the server goes down, all services are unavailable. Therefore, it is necessary to build a cluster here, which will waste server resources. Another point is that every time you verify, you need to check with this server, which will increase the network overhead and reduce the access speed

Cookie: the state information is no longer saved in the server, but in the client. Every time the client visits the server, it brings the information to the server. However, cookies also have many problems. The most concerned problem is security. Because information is stored on the client, it is easy to be stolen and tampered with. Of course, there are solutions to these security problems. This is not the main reason for restricting cookies. The real reason for restricting cookies is that many devices do not support * * cookies

Token: similar to cookie, token is maintained by client, and information is stored in client, which is platform independent. A token is essentially a string given by the server to the client, which contains some authentication information. It is equivalent to an identity token. You can get its service with this token. Compared with cookie, token is more flexible and can be generated anywhere. The permission system based on token is very easy to implement

Of course, the above five solutions are not the only ones. I just listed a few representative ones.

Solutions are used to solve problems. There is no good saying about the above solutions. Only the right one is the best.

The video cannot be played because you have disabled the cookie

Today, I suddenly want to see “happy dramatist”, Google browser Click to play, the result is “because you disable the cookie, the video can’t play…” this situation…

It’s not a big problem either. I just found out where the cookie is after a round of setting. It’s still Baidu… So it’s this

In content settings

OK, I don’t have any problem. I just didn’t know what happened before. I went back to refresh the website and came out… It’s so funny. I don’t know if I can refresh the web page before. But at least we can find something that we hope we can use in the future.

Illegalargumentexception: control character in cookie value or attribute tomcat7

It is disgusting to encounter this exception. In Tomcat7 environment, this exception will be raised if the user’s name appears in Chinese when logging in. After the exception is caused, the user who cannot log in normally needs to delete the browser’s cookie information. Later, I checked the Internet and found out that the problem was Chinese transcoding. The abnormal information is as follows:

java.lang.IllegalArgumentException: Control character in cookie value or attribute.     
    at org.apache.tomcat.util.http.CookieSupport.isV0Separator(CookieSupport.java:155)     
    at org.apache.tomcat.util.http.Cookies.processCookieHeader(Cookies.java:323)     
    at org.apache.tomcat.util.http.Cookies.processCookies(Cookies.java:157)     
    at org.apache.tomcat.util.http.Cookies.getCookieCount(Cookies.java:98)     
    at org.apache.catalina.connector.CoyoteAdapter.parseSessionCookiesId(CoyoteAdapter.java:913)     
    at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:683)     
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:400)     
    at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:964)     
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:515)     
    at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:304)     
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)     
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)     
    at java.lang.Thread.run(Thread.java:662)

Cookie is encoded by Unicode in Chinese and ASCII in English when storing the value, so the data needs to be transcoded when storing the Chinese value, and the data also needs to be transcoded when storing the value.
There are two solutions, one is a Cookie written in Java, and the other is a Cookie written in JavaScript.
The solution is as follows:
Java:

Encode: URLEncoder. Encode (name, “UTF-8”);
Decode.decode (name, “UTF-8”);
Decode.decode (name, “UTF-8”);

JavaScript:

Code: the escape (name);/encodeURI(name);
decode: unescape(name);/decodeURI(name);

The Servlet setting cookies to view the article: http://blog.csdn.net/twilight041132/article/details/46482983

Illegalargumentexception error when adding cookie to response

Many people often make this mistake when learning cookies. Someone asked me this question today, so I will share with you the solution to this problem (there is no specific solution on the Internet).
error code:

Cookie cookie=new Cookie("name","value value2");
response.addCookie(cookie);

Error
Java. Lang. IllegalArgumentException: An invalid character [32] was present in the Cookie value
Error code:

Cookie c=new Cookie("name","value,value2");
response.addCookie(c);

Error:
Java. Lang. IllegalArgumentException: An invalid character [44] was present in the Cookie value
…
the exception can be seen that this problem belongs to the invalid parameters, looking at the back of the prompt content
the An invalid character [44] was present in the Cookie value
cookies are invalid characters in character [44], so we query ASCII code is 44 said
“, “said 32 Spaces so we only need to replace the value of the corresponding characters, or coding

If the iframe in IE refers to the cross domain site page, the session fails

Problem scenario:

Personal confidence page through the IFrame nested third party page, domain name is different, call the third party interface, in Chrome test normal, in Internet Explorer is embedded in the page Session invalidation. (Session is based on cookie implementation, reference page is not allowed to use cookie)

Problem analysis:

The IE-supported P3P(Platform for Privacy Preferences Project (P3P) Specification) protocol by default prevents third party cookies without Privacy security claims, and Firefox does not currently support P3P security features, nor does it naturally exist in Firefox.

Solutions:

1. Modify the setting of the Client
so that the Client can accept cookies from any website (specifically set in the privacy page of IE option to add B site to the trusted site)
or set both domains to the trusted site

2. The domain of the application modifies the
simple scheme: two applications use the same domain
Complex solution: you can force changes to

through setdomain in pages loaded by the iframe. 3. P3P
first: output the host header declaration of P3P in the content to be embedded (the site the iframe points to) as follows:
Open IIS Manager InetMgr to be embedded in the iFrame source site or directory, right-click to open the Properties box and toggle to HTTP headers Add custom HTTP headers P3P Custom HTTP headers CP=”CAO PSA OUR” Close the properties box and exit, effective immediately
Response.addheader (“P3P”,”CP=CAO PSA OUR”);

Transfer: https://www.cnblogs.com/weibozeng/archive/2013/11/06/3410904.html