Speaking purely from the backend, our login function takes the IP address of the requester, the login name, and password, then checks the password against the database. If the password matches up, the current date and time, the current IP, the current time, the session expiration date, and a buttload of details about the host machine are hashed together and encrypted with the system's public key before being sent back as a token.
It's up to the client to store the token however it likes, but our reference implementation stores it as a cookie on the local machine.
If a new request comes from an IP address which doesn't match the encrypted token, or if there are system details in the encrypted token which don't match up with the one on file (we restrict sessions to single instances), then the request is rejected.
Comments
Speaking purely from the backend, our login function takes the IP address of the requester, the login name, and password, then checks the password against the database. If the password matches up, the current date and time, the current IP, the current time, the session expiration date, and a buttload of details about the host machine are hashed together and encrypted with the system's public key before being sent back as a token.
It's up to the client to store the token however it likes, but our reference implementation stores it as a cookie on the local machine.
If a new request comes from an IP address which doesn't match the encrypted token, or if there are system details in the encrypted token which don't match up with the one on file (we restrict sessions to single instances), then the request is rejected.
thanks, so basically you're hashing a token a each time a request comes in you decode.. do you increase the session expiration date or keep it as is?