WO2009076187A2 - Préservation de système client-serveur d'informations d'état mis en réseau par l'intermédiaire d'un protocole sans état - Google Patents

Préservation de système client-serveur d'informations d'état mis en réseau par l'intermédiaire d'un protocole sans état Download PDF

Info

Publication number
WO2009076187A2
WO2009076187A2 PCT/US2008/085639 US2008085639W WO2009076187A2 WO 2009076187 A2 WO2009076187 A2 WO 2009076187A2 US 2008085639 W US2008085639 W US 2008085639W WO 2009076187 A2 WO2009076187 A2 WO 2009076187A2
Authority
WO
WIPO (PCT)
Prior art keywords
application
session
user
client
server
Prior art date
Application number
PCT/US2008/085639
Other languages
English (en)
Other versions
WO2009076187A3 (fr
Inventor
Praveen Kallakuri
Keerat Sharma
Vishal Santoshi
Original Assignee
Gallup, Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Gallup, Inc filed Critical Gallup, Inc
Priority to EP08859639A priority Critical patent/EP2235881A2/fr
Publication of WO2009076187A2 publication Critical patent/WO2009076187A2/fr
Publication of WO2009076187A3 publication Critical patent/WO2009076187A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/30—Managing network names, e.g. use of aliases or nicknames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/142—Managing session states for stateless protocols; Signalling session states; State transitions; Keeping-state mechanisms

Definitions

  • This invention is related to computers and computer networks.
  • the invention is related to computers preserving state while communicating over networks.
  • Network protocols provide standard methods for machines to communicate with one another The protocols indicate how data should be formatted for receipt and transmission across networks. Heterogeneous machines can communicate seamlessly over a network via standard protocols, f0004] A client and server may communicate either synchronously or asynchronously.
  • a client waits for a response from a server before issuing the next request, hi an asynchronous communication, the client may issue a request to a server before one or more responses from previous requests to the server have been received,
  • [00061 State is used to frequently determine what to do next For instance, in a linear application where a user is required to walk through a sequence of questions, the state of the user might be used to keep track of the current question they are answering so that the application can determine what question to ask them next Alternatively, the state of the user might keep track of the questions, and the responses that they have been asked so far. Typically, an application will leverage the user state to provide outputs and require inputs from the user based on the context of ihe user that has been built up in ihe specific state that pertains to the user in question,
  • State can be maintained and worked with in a variety of ways.
  • a stateful system each interaction between user and application is taken into context with all the previous interactions- quite akin to a phone conversation.
  • the state is the mutation of one continuous transaction.
  • Interactions with a Word-Processing document, or an Interactive Voice Response (IVR) based bill payment system arc typical examples of a stateful session.
  • the application assumes complete responsibility for maintaining ihe current state, and mutating it as needed. The user just has to keep the transaction open for their state to remain intact.
  • cookies can help maintain some information
  • cookies cannot be relied upon to support applications accessed via stateless protocols, sessions associated with the applications, and resources associated with such applications and sessions, since users may reject cookies (e.g. for security and/or privacy reasons), and/or browsers, employed by remote clients may not support cookies.
  • any support avaialabie via cookies is limited to the restrictions imposed by the end-user (client) which limits its use as a universal solution to session/state management over HTTP.
  • client As a user interacts with an application, the application can request that the user store an arbitrary set of key- value pairs as a result of a transaction.
  • the cookies are parcels of text (key- value pairs) set by a server and expected as part of subsequent requests to the- domain the server represents.
  • HTTP cookies are used for authenticating, tracking, and maintaining specific information about users, such as site preferences and the contents of their electronic shopping carts.
  • cookies are arbitrary pieces of data chosen by the Web server and sent to the browser. The client is expected to return them unchanged to the server, introducing a state (memory of previous events) into otherwise stateless HTTP transactions.
  • each retrieval of a Web page or component of a Web page is an isolated event, mostly unrelated to all other views of the pages of the same site.
  • the browser provides the server a means of connecting the current page view with prior page views.
  • cookies can also be set by a script in a language such as JavaScript, if supported and enabled by the Web browser.
  • the application expects, and the user is obligated to provide those tokens bark to the application without tampering them. This is an effective mechanism, but has a number of obstacles. For one, if the user is to travel to a different machine to interact with the application, they would have lost their state and then need to reconstruct it. Additionally, if a user can not store the tokens provided, or suffers from a malicious attack that alters or steals those tokens, the user is liable for loss of data or confidentiality.
  • the browser thai is displaying the page sends a lequest over the Internet to the server associated with the Universal Resource Locator (URL) specified in the link.
  • URL Universal Resource Locator
  • the server transmits the requested information to the browser that issued Uw request.
  • the browser receives the information, presents the received information to the user, and awaits the next user request.
  • An easy mechanism to enable the application io overcome the weaknesses inherent to the cookie type mechanism is to encode the required tokens thai the application will need directly into the available inputs that the user will be making a choice from within the results from the prior transaction.
  • the application responded to the user with a possible input with embedded tokens that might have been generated/stored as a result of transactions in the past. Regardless, if the user chooses the input in question, then the application will be guaranteed to receive the tokens as listed in the example.
  • Cookies are key-value pairs that the application (in this case, the search engine) has provided back to the client. See “Persistent Client State HTTP Cookies", Netscape Communications Corporation, i 996, hUp ⁇ /home.netscape.com/newsref/std/cookie.sub.-- spec.html.
  • a server can satisfy an HTTP request by appending a state object known as a cookie to its response.
  • the cookie contains a set of domains to which the data it contains is applicable-
  • the cookie is stored by the browser running on the client. Any future HTTP requests made by the client to one of the URL's specified in the cookie will include a transr ⁇ ittal of the state object stored in the cookie from the client back to the server.
  • the application expects these tokens to be returned on subsequent requests.
  • URL rewriting covered previously too is where the user would be provided with links that contain embedded information that the application can strip out to process where the user was, relative to what they are asking for now,
  • the Plvper-Text-'Iransfer-Protoco! more commonly known as HTTP is a stateless protocol, it does have a number of mechanisms to allow for stateful applications to be built over it though.
  • a simple use-case that embodies managing state is a search engine.
  • a user provides a search page with a word, or set of words to search on. This input is handed to the search engine via a form executing a get or post action.
  • the search engine scrapes the known variable name ' s values from the request and executes a search, providing the user with results. While this first step might have been atomic, and rransactional, the search engine typically provides some form of pagination if the results are more than a fixed number in size. This is then managed via either URL re-writing, or by cookies.
  • the present invention opts to leverage the concept of URL re-writing to implement the session management technique described, though cookies may also be used.
  • URL re-writing does not hinge on the client machine behaving in accordance with assumptions that the application expects to be fulfilled. Instead, the application is assured that each successive interaction will contain tokens that the application has set by mutating the possible inputs with the tokens it needs as it sends a response to the user.
  • the session token is a unique identifier that is generated and sent from a server ⁇ o a client to identify the current interaction session.
  • the present invention allows the clien! to store and send the token as a part of the URL siring,
  • FIG. 1 illustrates a schematic block diagram illustrating a system for managing state information for applications accessed over stateleSvS protocols, in accordance with an aspect of the present invention
  • FIG. 2 illustrates a schematic block diagram further illustrating a system for managing state information for applications accessed over stateless protocols, in accordance with an aspect of the present invention
  • FIG. 3 illustrates data contained in a session object according to an exemplary embodiment of the present invention
  • FIG. 4 illustrates an exemplary data structure in a V RL siring according to an exemplary embodiment of the present invention
  • FIG 5A is an exemplary communication flow between a client and a server according to an exemplary embodiment of the present invention
  • FlG. SB is an exemplary communication flow between a client and a server according to an exemplary embodiment of liie present invention
  • FIG. 1027 is an exemplary communication flow between a client and a server according to an exemplary embodiment of liie present invention.
  • FIG. 6 A is an exemplary client identification table according to an exemplary embodiment of the present invention
  • FlG 6B is an exemplary client identification iable according to an exemplary embodiment of the present invention
  • FIG, ⁇ C is an exemplary client identification tabic according to an exemplary embodiment of the present Invention
  • FIG 7 illustrates a flow chart for preserving state in a stateless server environment according to an exemplary embodiment of the present invention DETAILED DESCRIPTION OFTHE INVENTION
  • a component can be, but is not limited to being, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer.
  • a component can be, but is not limited to being, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer.
  • an application running on a server and the server can be a module.
  • One or more components can reside within a process and/or thread of execution, and a module or component can be localized on one computer and/or distributed between two or more computers.
  • the terms “desktop,” “PC,” “local computer,” and the like refer to computers on which systems (and methods) according to the invention operate.
  • these are personal computers, such as portable computers and desktop computers; however, m other embodiments, they may be other types of computing devices (e.g., workstations, mainframes, personal digital assistants or PDAs 5 music or MP3 players, and the like).
  • ⁇ client is a computer which issues requests or commands to the server which performs ihe task associated with the request or command.
  • a state is the complete set of properties transmitted by an object to an observer via one or more channels. Any change in the nature or quantity of such properties in a state is detected by on observer and thus a transmission of information occurs.
  • Any computer that performs a task at the command of another computer is a server.
  • Web server typically supports one or more clients.
  • a session is either a lasting connection using the session layer of a network protocol or a lasting connection between a user and a server, usually involving the exchange of many packets between the user's computer and the server.
  • a session is typically implemented as a layer ui a network protocol.
  • the Internet's application that lets people seeking information on the Internet switch from server to server and database to database by clicking on highlighted words or phrases of interest (hyperlinks).
  • An Internet WWW server supports clients and provides information.
  • the Web can be considered as the Internet with all of the resources addressed as URLs and which uses HTML to display the information corresponding to URLs and provide a point-and-ehck interface to oiher URLs
  • a way to uniquely identify or address information on the Internet Can be considered to be a Web document version of an e-mail address.
  • URLs can be cumbersome if they belong to documents buried deep within others. They can be accessed with a Hyperlink, An example of a URL is "hitp://www.amn,com:8Q/tabie.htmr ⁇
  • a URL has four components Starting from the left, the first specifies the protocol to use, separated from the rest of the locator by a ":".
  • HTML HyperText Markup Language
  • HTML is the language used by Web servers to create and connect documents that are viewed by Web clients.
  • HTML uses Hypertext documents.
  • Other uses of Hypertext documents are described in U.S. Pat, No. 5,204,947, granted Apr. 20, 1993 to Bernstein et a!.; U.S. Pat. No. 5,297,249, granted Mar. 22, 1994 to Bernstein et al; U.S. Pat No, 5,355,472, granted Oct. 11 , 1994 to Lewis; all of which are assigned to international Business Machines Corporation, and which are incorporated by reference herein,
  • HTTP is an example of a stateless protocol, which means that every request from a elienl to a server is treated independently. The server has no record of previous connections. At the beginning of a URL 3 "http:" indicates the file contains hyperlinks.
  • a program running on a computer that acts as an Internet tour guide, complete with pictorial desktops, directories and search tools used when a user "surfs" the Internet.
  • the Web browser is a client service which communicates with the World Wide Web.
  • the application can be, for example, email, chat sessions, online shopping, video games, web-enabled applications and search engines. Although six applications are listed above, it is to be appreciated by one skilled in the art that any application for winch tracking state and/or user information is beneficial may be employed with the present invention.
  • the application 30 can be hosted by a server 20, The server 20 can be, for example, a personal computer, a workstation, and one or more distributed machines co-operating in serving the application 30.
  • the stateless protocol can be, for example, a Hypertext Transfer Protocol (HTTP).
  • the application 30 may be accessed by a remote user employing a browser 40.
  • Browser 40 may be suitable HTTP client of HTTP agent.
  • the browser 40 and the server 20 may communicate via the stateless protocol.
  • stateless protocol requests and/or responses may travel between the browser 40 and the server 20.
  • One or more resources 70 may be associated with the application 30.
  • the resources can include, but are not limited to memory, network bandwidth, processor time and communication devices.
  • the server 20 can manage the resources 70 that are allocated to the application 30.
  • the application 30 can be an application that can be accessed by more than one remote user. Thus, the application 30 may have resources 70 allocated for the more than one remote user.
  • the user enters the LIRL for a Web document into a browser program.
  • the browser 40 then sends an http request to the server 20 that has the Web document using the URL.
  • the Web server responds to the http request by sending the requested HTTP object to the client.
  • the HTTP object is a plain text document containing text that is written in HyperTcxt Markup Language (HTML)
  • HTML HyperTcxt Markup Language
  • the HTML document usually contains hyperlinks to other Web documents.
  • the browser 40 displays the HTML document on the screen for the client ancl the hyperlinks to other Web documents are emphasized in some fashion such that the client can select the hyperlink.
  • the applications 32, 34, 36 may be, for example, an email application, an electronic payment application and/or a lask list application.
  • Remote clients can access one or more applications 32, 34, 36 (collectively the applications 30) via the stateless protocol 45.
  • Remote clients may access the applications 30 from one or more browser sessions 102, 104, 106 (collectively the sessions 100).
  • the present invention facilitates creating one or more session objects 62, 64, 66 operable to contain state information about remote clients and associated sessions.
  • One or more remote clients 42, 44, 46 access the applications 30 via the stateless protocol 45.
  • the remote clients 42 can send requests to the applications 30 via the stateless protocol and can receive responses from the applications 30 via the stateless protocol.
  • the requests and responses can be employed to cany information that facilitates storing state information in the one or more session objects 62, 64, 66.
  • each session object 62, 64, 66 can be created to facilitate tracking the state and user specific information employed by the applications 30.
  • the server 20 comprises a Session Manager 50.
  • the Session Manager 50 is a component that creates, modify or remove the session objects 62, 64, 66.
  • each session object 62, 64, 66 may contain various data including, but not limited to, (1) an Application ID 310, (2) an Interaction ID 320. (3) an Entity TD 330, (4) a Time 340, (5) an Iteration 350, (6) an Authentic flag 360, and/or (7) a Data container 370.
  • the first request for an application 30 from a cheat 40 wiH be a hit to the application 30 without any specific URL artifacts, such as: http://gx.gailup.cora/appl. It only contains a "real' " URL.
  • the Session Manager 50 determines if the URL for the HTTP request can be fractured to reveal any artifacts (step 740).
  • the artifacts within the URL include: (1) the request type; http (as opposed to hffps, or any other protocol), (2) the host (gx.gallup.com), and (3) the resource, or application requested (appl).
  • the Session Manager 50 reconciles the supplied information to a given identifier which is referred as an Application ID 310. If the URL includes state information, the Session Manager 50 evaluates the state information (step 750).
  • the Session Manager 50 can conclude that the client making the request is either arriving at the application for the first time, or has not provided the application with enough information to make themselves known yet.
  • the Session Manager 50 creates a universally unique identifier to track the client (user ID).
  • the Session Manager 50 checks its persistence layer for the presence of an Interaction identifier (Interaction Id) that associates a specific User ID 3S0 with an Application ID 310, According to one embodiment, when a browser request is received that does not contain any interaction ID, the Session Manager 50 creates a globally unique Interaction ID 320.
  • the Interaction ID 320 includes the user ID 380 and the Application ID 310.
  • the Session Manager 50 defines a tuple with, respect to the Interaction ID 320, such as (User ID, Application ID). Iu this instance, the tuple includes a group including the User ID 380 and the Application ID 310.
  • the Session Manager 50 then creates a fresh Session object 62, 64, 66.
  • the Session object 62, 64, 66 stores the Time 340 that it was created,
  • the Session object 62, 64, 66 maintains a counter named Iteration 350. Since the session has just begun, the Iteration counter 350 is initialized to 0.
  • the Iteration 350 is a counter that keeps track of how many times the Session Manager 50 has seen the user interact with the system, ⁇ t has further utility in determining state rollback and the like, covered later in Detection Mechanisms for State Rollback.
  • Session object 62, 64, 66 is initialized with an authentic flag
  • the application is responsible for managing this flag 360 by translating what the user has supplied, processing it and determining whether to keep the session authentic. For this first hit though, the session remains non-authentic.
  • Data Container 370 is a receptacle that can store arbitrary key-value pairs.
  • the application can use the Data Container 370, via the Session object 62, 64, 66, as a place to store arbitrary data.
  • the Data Container 370 is to be leveraged as an intermediate space between the way in which the transport protocol in question passes parameters, and the applications execution layer. This allows specific transport protocols to manage their specific parameter extraction mechanisms and place them w the relevant Data Container 370, while still allowing the execution layer to work in a transport protocol agnostic fashion.
  • the Data Container 370 serves to allow the execution layer to place arbitrary variables and their values in a region relevant to the client and application.
  • the Session Manager SO has established, created or updated a specific Session object 62, 64, 66.
  • the created Session object 62, 64 ; 66 is returned by the Session Manager 50 to the application 30.
  • the application 30 then proceeds with whatever logical execution flow it needs Io in order to respond to the client. Since it has the Session object 62, 64, 66 in hand, it has the ability to interrogate it for things like the User ID 380, or the specific time. Also, the application has the ability to store arbitrary data within the Data Container via the Session,
  • the application 30 is the ability to create hooks back to the session (links in HTTP/HTML) that reference the same session.
  • the application 30 processes a request, it comes up with possible resources that it deems legal for the user to see next, These could be a form including a usemame and password with a submit button that calls a component to authenticate a user, or a page with numerous links that allows the user to get specific areas within the application.
  • the application must demand the links to be created by the Session object by providing it with an action, command or resource that it will be able to logically process if the user chooses that link, or form.
  • the Session object 62, 64, 66 Is able to accept the execution directive from the application 30 and concatenates it with artifacts that it already knows to construct a tokcnizcd String 400-
  • the tokenized string 400 can include the Application ID 310, the Interaction ID 320, the User ID 380, the Iteration 350 » the Time 340, and the execution directive 410,
  • the session objects 62, 64, 66 60 can be managed by a Session Manager 50 70.
  • the Session Manager 50 70 can be responsible for actions including, but not limited to, initializing the session objects 62, 64, 66, for maintaining the session objects 62, 64, 66 and/or for reclaiming memory from session objects 62, 64, ⁇ thai are no longer tracking stale and/or user information, for example. Tn one example aspect of the present invention, the Session Manager 50 can monitor how long it has been since a session objects 62, 64, 66 was accessed.
  • the Session object 62, 64, 66 would have initialized the iteration 320 to zero, and so all the provided links from the Session back to the application would have the iteration augmented to one.
  • the String 400 may then be encrypted, preferably with a quick symmetric algorithm like Blowf ⁇ sh. After encryption, the link is then compressed. Numerous other encryption and compression methods will be readily apparent to those of ordinary skill in the art. For example, asymmetric encryption algorithms may be used. Such alternative methods maybe substituted relatively easily to conform with any desired standard. [0064J
  • the application execution proceeds, and when done, responds back to the user with the result. Tn our example so far, this would probably be a page that allows the user to authenticate, or pick some direction to start with. Only after the user has successfully provided with the response to the processing of the application 30 does the Session Manager 50 persist the contents of the Session.
  • the contents of the Session are persisted by iteration.
  • the Session related artifacts that are stored include the Interaction ID 320, with the corresponding Entity ID 330 and Application TD 310.
  • the Session Manager 50 Upon making their first request to the application 30, the Session Manager 50 has created an interaction ID 320 for the corresponding Application ID 310, and has generated a User TD 380 for the user in question. Application processing resulted in some forms/links being generated that will aid the application in identifying the user. The user is presented with a page that prompts them to enter some data and submit it.
  • the application layer 30 Upon submission, the application layer 30 first extracts any HTTP specific parameters that came with the request. These might include answers to questions as form ⁇ saa, parameters on the URL as per how HTTP defines key-value pair submission on a URL via the GET protocol. Regardless of how they arrived, the application is responsible to harvesting them from the request. It then hands both the user submitted values as well as the user requested URL Io the Session Manager 50. f 0069J The Session Manager 50 is responsible for decompressing the URL. Then, it deciphers the decompressed text.
  • the Session Manager 50 proceeds to extract these tokens, as shown in Fig. 4. In the event that the decompression or decryption fails, the Session Manager 50 may automatically discard the corrupted session string and start afresh.
  • the Session Manager 50 queries the persistence layer to ensure that an interaction ID 320 does indeed exist, and in fact correlates to the tuple consisting of the Application ID 310 and Entity ID 330 If this does exist, the Session Manager 50 assembles a Session object 62, 64, 66 based on the interaction 320.
  • the Session object 62, 54, 66 is reconstructed by rc-assembling the Data
  • the Session Manager 5 ⁇ can cache the Session object 62, 64, 66 even after it has been persisted from the prior request, since there is a strong likelihood that a subsequent request will need to leverage the object anyway, Once the session has been constructed, the Session Manager 50 transfers control back to the application 30.
  • the application 30 is free to use the Session data to continue logical processing. At some point, the application 30 should choose to authenticate the user. The desired inputs from the user to challenge authentication will be present in the user's session, and the application 30 can harvest and logically leverage them to determine who the user is. The end result of this operation is for the application 30 to determine the actual User ID 3S0 for the user in question, or for the application 30 to create a new one, hi the event that the application needs to create a new one, it registers the User ID 380 with the Session Manager 50. ⁇ (H)73J According to one embodiment of the Invention, a timeout value is associated with each transaction.
  • the timeout value is used to identify multiple-request transactions that have uot been active for a specified time period.
  • the Session Manager 50 compares the extracted time from the URL with the current time.
  • the URL time must be less Chars the current time since the time on the IJRL was the time when the prior request was processed.
  • the time difference therefore, is the amount of time that the user took to trigger a subsequent request. This can be very useful in helping the application logic layer determine how it wants to treat certain incoming values. If a user is only to be given 20 seconds to answer a specific question on a web page, this mechanism allows the logical layer of the application to make a decision on how to treat a time-sensitive response from the user,
  • J0074J Another important aspect to being able to analyze the total time taken between the current and last request allows the Session Manager 50 to determine (with parameters in the application) whether the user has "timed out," If the duration exceeds the default, or application specific threshold, the Session Manager 50 assumes that the user will need to authenticate again. To facilitate this, the Session Manager 50 removes the authentication flag 360 from the user's session. The application 30 can then act on this and direct the user to a page that a non- authenticated user would see- quite likely a login page. Upon re-authenttcation, the user's session would remain intact from their prior location, and the application processing, which is dependent on the session will resume from where the user was last at.
  • the Session Manager 50 supports a direct request from the application layer to inactivate a particular session. Typically, this would he triggered by a user opting to log out of an application 30 that they are currently authenticated against. The mechanism proceeds in the same way as the timeout instance, setting the authentic flag 360 on the session to false so that the application 30 can no longer proceed with leveraging the contents ⁇ f the session until the user has re-authenticated it.
  • the state information is assembled, the state information is incorporated into a URL.
  • This URL embedded within the response to the client request is returned to the requesting client.
  • the state information may be transactions! Iy persisted into some central data store.
  • the client submits a second request relating to the same operation
  • the client sends the URL that was previously provided by the server which contains the state information.
  • the server extracts the state information from the URL, and uses it to resume the previously initiated operation. With the benefit of this state information, the server can resume the operation at the exact point at which the previous request stopped.
  • the Session Manager 50 would initially provide them with a fresh non-aulhenticated session, just as it wouid with a first time user.
  • the application would challenge them, at some point to authenticate. If the user provides a legitimate set of credentials, or tokens, that the authenticator is able to leverage successfully, then it provides ihe Session Manager 50 with the relevant User ID 310 and Application ID 310, derived logically from the user's input and from the executing application correspondingly. [00781 The Session Manager 50 first checks to see if the corabination of the
  • Application ID 310 and the User ID 380 yields an existing Interaction JD 320.
  • the Session Manager 50 now has to Feconcite the user's prior session, with the new session that the user has so far used to authenticate. To do this, the Session Manager 50 augments tho contents of the previous session with the contents of the current session. The current temporary session is merged back onto the users' prior session. The contents of the new session's Data Container 370 are augmented to ihe old session in iterations that increment from where the old session left off.
  • the Session Manager 50 leaves completes execution io have the session pegged to the original Interaction ID 320, the user's User ID 380 « the application's Application ID 310, the iteration 350 of the last authenticated Session plus the iterations on the temporary new session.
  • the Session Manager 50 reconciles an existing session with the parameters fed to if that represent a user request.
  • the request contains session artifacts that allow the Session Manager 50 to locate the specific session that may or may not already exist for the request in question.
  • the Session Manager 50 has a lot of knowledge about the user session so far. This includes the time that the last hit was made (used in determining potential timeouts), as well as the last iteration for the session,
  • the Session Manager 50 Since the Session Manager 50 knows the last iteration for a &iven interaction, it can know to expect a subsequent request that has an iteration incremented by one for the incoming request, as illustrated in Fig. 5 A, [0081] In the event that the Session Manager 50 gets a request with an iteration out of sequence, it knows that something is amiss, as illustrated in Fig. 5B, En the scenario shown, the Session Manager 50 was supplied a request more than once (iteration 17).
  • Manager 50 might get subsequent requests that contain iterations that are more than one increment less than the expected iteration, in these situations, the user has typically gone back more than once, bookinarked a link, or has chosen to interact with the system from two different clients.
  • the Session Manager 50 is able to react to this scenario.
  • keys that arc re-dcclar ⁇ d or mutated by the application take precedence over keys that were declared in the past.
  • the Session Manager 50 would make the value of ql be 4 when the application queries the session for the value of ql.
  • the session persistence layer is the central area where all sessions arc broken down and stored.
  • the persistence layer can be structured in many ways. However, the persistence layer needs to be able to retrieve a user session or resume on one quickly.
  • FIG. 6B a simple table containing interaction IDs 621 with their corresponding user ID 625 and Application TD 623. Given two of the three, it is easy to determine the third. Typically, the application will have enough information to determine a user ID 625 (via authentication) and the Application ID 623 in question.
  • Fig. 6C a table that stores the different iteration response sets.
  • the data set helps break down the session into the constituent iteration frames and their constituent key- value data pairs.
  • each transaction from the user is fractured and stored into the corresponding iteration for the session, we have a mechanism available that allows us to break the entire lifespan of user interactions with the application into discrete events. Each event is tagged with the time it occurred, the command executed by the user, and all the variables that constituted the transaction. This data helps break down the session into the constituent iteration frames.
  • first and second are used herein to describe various features, elements, regions, layers and/or sections, these features, elements, regions, layers and/or sections should not be limited by these terms. These terms are only used to distinguish one feature, element, region, layer or scclion from another feature, element, regioa, layer or section, Thus, a first feature, element, region, layer or section discussed below could, be termed a second feature, element, region, layer or section, and similarly, a second without departing from the teachings of the present invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention porte sur un procédé, exécuté par un serveur pour maintenir un état dans un environnement de serveur sans état, qui comprend la réception d'une demande pour exécuter une opération par une application à partir d'un client, la demande comprenant un premier localisateur de ressources uniformes (URL). Un premier ensemble d'informations d'état peut être extrait d'un premier URL, s'il y en a de présent, et évalué. Un second ensemble d'informations d'état associé à l'opération est assemblé, et le second ensemble d'informations d'état contient au moins les informations d'identification de client, les informations d'application et un compteur. Le compteur garde une trace du nombre de fois où le client a interagi avec le serveur pour l'opération. Le second ensemble d'informations d'état est incorporé dans un second URL.
PCT/US2008/085639 2007-12-07 2008-12-05 Préservation de système client-serveur d'informations d'état mis en réseau par l'intermédiaire d'un protocole sans état WO2009076187A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP08859639A EP2235881A2 (fr) 2007-12-07 2008-12-05 Préservation de système client-serveur d'informations d'état mis en réseau par l'intermédiaire d'un protocole sans état

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12244407P 2007-12-07 2007-12-07
US61/012,2444 2007-12-07

Publications (2)

Publication Number Publication Date
WO2009076187A2 true WO2009076187A2 (fr) 2009-06-18
WO2009076187A3 WO2009076187A3 (fr) 2009-08-27

Family

ID=40756070

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2008/085639 WO2009076187A2 (fr) 2007-12-07 2008-12-05 Préservation de système client-serveur d'informations d'état mis en réseau par l'intermédiaire d'un protocole sans état

Country Status (2)

Country Link
EP (1) EP2235881A2 (fr)
WO (1) WO2009076187A2 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011035944A1 (fr) * 2009-09-25 2011-03-31 International Business Machines Corporation Gestion d'informations d'état d'application au moyen d'un identifiant uniforme de ressource (uri)
WO2012178167A2 (fr) 2011-06-24 2012-12-27 Usablenet Inc. Procédés permettant à des applications web ajax d'être mises en signets et d'être parcourues, et dispositifs associés
CN105659220A (zh) * 2013-07-26 2016-06-08 开放电视公司 数字电视网络中的测量响应趋势

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5961601A (en) * 1996-06-07 1999-10-05 International Business Machines Corporation Preserving state information in a continuing conversation between a client and server networked via a stateless protocol
WO2001089170A2 (fr) * 2000-05-17 2001-11-22 Interactive Video Technologies, Inc. Procede de conservation d'etat dans des communications basees sur http
US6460071B1 (en) * 1997-11-21 2002-10-01 International Business Machines Corporation System and method for managing client application state in a stateless web browser environment
EP1457892A1 (fr) * 2003-03-12 2004-09-15 Microsoft Corporation Gestion d'information d'état à travers des sessions de communication entre un client et un serveur par l'intermédiaire d'un protocole sans état

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5961601A (en) * 1996-06-07 1999-10-05 International Business Machines Corporation Preserving state information in a continuing conversation between a client and server networked via a stateless protocol
US6460071B1 (en) * 1997-11-21 2002-10-01 International Business Machines Corporation System and method for managing client application state in a stateless web browser environment
WO2001089170A2 (fr) * 2000-05-17 2001-11-22 Interactive Video Technologies, Inc. Procede de conservation d'etat dans des communications basees sur http
EP1457892A1 (fr) * 2003-03-12 2004-09-15 Microsoft Corporation Gestion d'information d'état à travers des sessions de communication entre un client et un serveur par l'intermédiaire d'un protocole sans état

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011035944A1 (fr) * 2009-09-25 2011-03-31 International Business Machines Corporation Gestion d'informations d'état d'application au moyen d'un identifiant uniforme de ressource (uri)
WO2012178167A2 (fr) 2011-06-24 2012-12-27 Usablenet Inc. Procédés permettant à des applications web ajax d'être mises en signets et d'être parcourues, et dispositifs associés
WO2012178167A3 (fr) * 2011-06-24 2013-02-28 Usablenet Inc. Procédés permettant à des applications web ajax d'être mises en signets et d'être parcourues, et dispositifs associés
US8527862B2 (en) 2011-06-24 2013-09-03 Usablenet Inc. Methods for making ajax web applications bookmarkable and crawlable and devices thereof
US10015226B2 (en) 2011-06-24 2018-07-03 Usablenet Inc. Methods for making AJAX web applications bookmarkable and crawlable and devices thereof
CN105659220A (zh) * 2013-07-26 2016-06-08 开放电视公司 数字电视网络中的测量响应趋势
US10063450B2 (en) 2013-07-26 2018-08-28 Opentv, Inc. Measuring response trends in a digital television network
CN105659220B (zh) * 2013-07-26 2019-09-24 开放电视公司 数字电视网络中的测量响应趋势
US10581714B2 (en) 2013-07-26 2020-03-03 Opentv, Inc. Measuring response trends in a digital television network
US11146473B2 (en) 2013-07-26 2021-10-12 Opentv, Inc. Measuring response trends in a digital television network

Also Published As

Publication number Publication date
EP2235881A2 (fr) 2010-10-06
WO2009076187A3 (fr) 2009-08-27

Similar Documents

Publication Publication Date Title
US20110282939A1 (en) Preserving state information client-server system networked via a stateless protocol
RU2681699C1 (ru) Способ и сервер для поиска связанных сетевых ресурсов
US10104064B2 (en) Secure authentication systems and methods
US7222363B2 (en) Device independent authentication system and method
US6820125B1 (en) Method for coordinating actions among a group of servers
US6433795B1 (en) System for integrating an on-line service community with a foreign service
JP3407277B2 (ja) 通信方法、記録媒体及びウェブ・サーバ
US20070136477A1 (en) HTTP header intermediary for enabling session-based dynamic site searches
US7058892B1 (en) Displaying content from multiple servers
US7600027B2 (en) Managing multiple sessions for a user of a portal
US20020156812A1 (en) Method and system for assembling concurrently-generated content
US8838679B2 (en) Providing state service for online application users
US20060168645A1 (en) Apparatus and method for a personal cookie repository service for cookie management among multiple devices
US20010047477A1 (en) Transparent user and session management for web applications
WO2002080014A1 (fr) Assemblage de contenu de pages web personnalisees realisees parallelement
WO2004036351A2 (fr) Gestion d'authentification temporisee intersite
WO2003050700A1 (fr) Dispositif et procede pour l'utilisation de donnees d'etat de session entre sessions
US7805608B2 (en) User privacy through one-sided cookies
US20060143301A1 (en) Systems and methods for establishing and validating secure network sessions
US20090193127A1 (en) Systems and Methods for Establishing and Validating Secure Network Sessions
US6947979B1 (en) Controlling use of a network resource
CN108683651B (zh) 一种单点登录方法、服务端及系统
CN103957252B (zh) 云储存系统的日志获取方法及其系统
WO2009076187A2 (fr) Préservation de système client-serveur d'informations d'état mis en réseau par l'intermédiaire d'un protocole sans état
CN107343028B (zh) 一种基于http协议的通信方法及系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08859639

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2008859639

Country of ref document: EP