Android cookies are shared to WebView to avoid Logon (logon status is maintained) and androidwebview

Android cookies are shared to WebView to avoid Logon (logon status is maintained) and androidwebview

Recently, you used webview to open a webpage with a specified link. You can set a cookie for webview but always go to the logon page, this is because the cookie is not successfully set, and webview does not send the configured cookie ......

12345

CookieSyncManager.createInstance(context);CookieManager cookieManager = CookieManager.getInstance();cookieManager.setAcceptCookie(true);cookieManager.setCookie(url, cookies);// Cookies are cookies obtained in HttpClient.CookieSyncManager.getInstance().sync();

By using the above code, you can associate the previously saved cookies with the specified url to maintain the logon status and avoid repeated logon. Unfortunately, during the development process, I strictly set the cookie according to the above-mentioned cookie setting code. If the result still fails, I always go to the logon page and prompt to log on. Later, I checked the Android API documentation and found that the two parameters of the setCookie function are described as follows:

Public void setCookie (String url, String value) Added in API level 1

Sets a cookie for the given URL. any existing cookie with the same host, path and name will be replaced with the new cookie. the cookie being set must not have expired and must not be a session cookie, otherwise it will be ignored.

 

Url	The URL for which the cookie is set
Value	The cookie as a string, using the format of the 'set-cookier' HTTP response header The value parameter is used as a string of the cookie value, but the format must be the http Request Header Format "Set-Cookie ".

This sentence in the api document suddenly woke me up, so after Baidu I found the cookie format-related articles, I have excerpted the following:

Link: http://www.cnblogs.com/hdtianfu/archive/2013/05/30/3108295.html

Cookie-related Http headers

A connection to an Http header is related to the Cookie: Set-Cookie and Cookie. The Set-Cookie is sent by the server and contained in the response request header. It is used to create a Cookie header on the client that is sent by the client and contained in the header of the HTTP request. Note that this cookie is sent only when the domain and path of the cookie match the request URL.  Set-Cookie HeaderThe format of the Set-Cookie response header is as follows: Set-Cookie: = [; =]... [; expires =] [; domain =] [; path =] [; secure] [; httponly] expires =: Set the cookie validity period, if the cookie exceeds the date indicated by date, the cookie becomes invalid. If this option is not set, the cookie will expire when the browser is closed. Note: date is Greenwich Mean Time (GMT), expressed in The following format: DAY, dd mmm yyyy hh: MM: ss gmt day the day of The week (Sun, Mon, Tue, wed, Thu, Fri, Sat ). DD The day in the month (such as 01 for the first day of the month ). MMM The three-letter abbreviation for the month (Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec ). YYYY The year. HH The hour value in military time (22 wocould be P. M ., for example ). MM The minu Te value. SS The second value. domain =: path =: Note: Temporary cookies (cookies without The expires parameter) cannot contain The domain option. When the client sends an http request, the valid cookie is sent to the server together. If the domain and path parameters of a cookie match the URL, the cookie is valid.

A URL contains domain and path, refer to http://www.w3school.com.cn/html/html_url.asp

Secure: indicates that the cookie can only be sent to the http server. Httponly: indicates that the cookie cannot be obtained by the client script.

 

Generate expires in the program

C MethodTime_t curTime = time (NULL); tm * gmTime = gmtime (& curTime); char strExperis [50]; strftime (strTimeBuf, 100, "%, % d % B % Y % X GMT; ", gmTime ); JavaScript MethodVar d = new Date (); var expires = d. toGMTString ();

The bold red text above makes me more confident in my judgment. I don't need to say how excited I am at this moment.

So I added the domain and path fields to the original cookie string and ran it with expectation. Haha, the results are correct and no longer need to log on repeatedly.

After this bug resolution, we cannot let go of any details in the programming process. We need to clearly understand every running details so that we can avoid blindly solving the problem and finally waste time ......

Welcome to discussion group: 192209234

Who has done session persistence on the android client?

Use cookies to save the cookie value during logon and rewrite webview. In the method used to load the page, CookieManager processes the cookie value, and the login session is maintained.
 
How does Android httpClient Save the cookie globally? Access webview binding

The cookie is obtained, and it is not easy to save ????