Session|web
How to apply session to develop non-web terminals
Protocol S
-Author Sunggsun @ 20:27
Session is a more effective means of information interaction on the Web. It is favored by many web developers because of its convenient, stable, safe and reliable use. Especially in the Internet identity authentication, online electronic shopping and other aspects of the application is more extensive. Coincidentally, the author in the development of a financial project data center platform, that the data transfer part of the identity authentication and information interaction and web domain session control is very similar. So I wanted to try this new technology, and by looking at a lot of data, I thought it was also practical to interact with the session for non-web clients. After repeated testing successfully applied to the project, the results are significant, save a lot of temporary data preservation and the state detection of the lock, automatically maintained by the session state.
Good things can not be exclusive, the author wants to successfully apply the session control for non-web development key technical points to discuss together. We know that cookies are the most common way to track user conversations on the web, and when cookies are blocked, you typically use URL rewriting to track sessions. So what exactly is a cookie? By definition: A cookie is a fragment of information sent to a customer by the server, stored in a customer environment, and sent back to the client's request for the server. For example, when we use IE to log on to an electronic shopping mall, IE receives the Set-cookie reply header message while getting the Product List page. The format of this information is "set-cookie:name=value;" Comment=comment;domain=domainnmae; Max-age=seconds; Path=path;secure; Version=1*digit ", where the name value pair (separated by semicolons) is required and the rest is optional. The most important information, of course, is also in the necessary value pairs, value is name, and is the identity of this cookie, Max-age defines the maximum lifetime of the cookie, and several other optional value pairs can refer to http://www.faqs.org/rfcs/rfc2109.html. When we buy a product, send the purchase list to the server, it automatically adds a name value pair in the header of your request, and if the cookie is prohibited, append the name value pair to the URL request address with URL rewrite. When the Web server receives this request, it checks to see if the cookie exists and then tracks the session accordingly. From the above analysis is not difficult to understand, in fact, the Web server tracking session relies on Set-cookie header information, tracking name value pairs for authentication. If we use a non-web terminal to receive the Web server's response information, from which to parse out the cookie header information, when again send the request to the Web server appended with the parsed cookie information, the Web server can not be authenticated?
With the above analysis, it is also very convenient for us to write the code. Here is the demo code that I used to interact with the servlet in the Apache Tomcat 4.0 service engine with the C++builder 6 application for reference only.
The code for the C + + client when it first sends a request to the server is as follows:
Tidhttp *httpclient = new Tidhttp (NULL);
Tidheaderlist * hlist;
String url= "Http://localhost:8080/Rev/servlet/test";
Try
{
Try
{
Httpclient->get (URL);
if (httpclient->response!= NULL)
{
Hlist = httpclient->response->extraheaders;
String cookie = hlist->values["Set-cookie"];
int pos = cookie. Pos (";");
if (pos > 0)
session_id = cookie. SubString (1,POS-1);
Else
session_id = cookie;
}
catch (exception& E)
{
}
} __finally
{
Httpclient->free ();
}
The variable URL in the above code points to the HTTP address of the servlet in which it is assigned, and the variable session_id to the global variable, recording the cookie. The next time you interact, simply add "Httpclient->request->extraheaders->add" ("Cookie:" + session_id) before the httpclient request; "Apache Tomcat will automatically discriminate the validity. Is it easy?
The validation of the servlet server side is also easier, and the specific cookie authentication process lets the Apach tomcat engine do it as follows:
public void doget (HttpServletRequest request, httpservletresponse response) throws Servletexception, IOException {
Response.setcontenttype ("text/html; CHARSET=GBK ");
PrintWriter out = Response.getwriter ();
Out.println ("Out.println ("Out.println ("<body>");
HttpSession session = Request.getsession (false);
if (session!= null) {
Out.println ("<p> Status Confirmation </p>");
} else {
OUT.PRINTLN ("<p> certification failure </p>");
}
Out.println ("</body>}
The most critical of the code is "Request.getsession (false);", when the argument is true, Apache Tomcat creates a new session, and when the argument is false Apache Tomcat looks for the associated session based on the information in the request. So to maintain the continuity of the session, it must be invoked with the parameter false, but if the Session,apache Tomcat is not invoked for a long time, it will automatically invalidate the sessions, about Apache The management mechanism of Tomcat and its configuration can refer to http://jakarta.apache.org/.
Demo code with the C++builder tidhttp components, the component in strict accordance with the HTTP specification implementation, Delphi also has this component, Visual C + + also has similar MFC, according to their familiar development platform debugging, The servlet program used for authentication must be loaded on Apach tomcat for debugging and restart Apach Tomcat. The above code is only for demonstration, to actual application also need to add a variety of exception handling and HttpClient request package and servlet Response Response package processing, interested friends can email : 21cnDeveloper@163.com further exchanges with the author.
