zealfire · March 11, 2018 18:40
diff --git a/session vs cookies b/session vs cookies
 A cookie is simply a short text string that is sent back and forth between the client and the server. You could store name=bob; password=asdfas in a cookie and send that back and forth to identify the client on the server side. You could think of this as carrying on an exchange with a bank teller who has no short term memory, and needs you to identify yourself for each and every transaction. Of course using a cookie to store this kind information is horrible insecure. Cookies are also limited in size.

 Now, when the bank teller knows about his/her memory problem, He/She can write down your information on a piece of paper and assign you a short id number. Then, instead of giving your account number and driver's license for each transaction, you can just say "I'm client 12"

 Translating that to Web Servers: The server will store the pertinent information in the session object, and create a session ID which it will send back to the client in a cookie. When the client sends back the cookie, the server can simply look up the session object using the ID. So, if you delete the cookie, the session will be lost.

 One other alternative is for the server to use URL rewriting to exchange the session id.

 Suppose you had a link - www.myserver.com/myApp.jsp You could go through the page and rewrite every URL as www.myserver.com/myApp.jsp?sessionID=asdf or even www.myserver.com/asdf/myApp.jsp and exchange the identifier that way. This technique is handled by the web application container and is usually turned on by setting the configuration to use cookieless sessions.

 SESSIONS ENDS WHEN USER CLOSE HIS BROWSER,

 COOKIES ENDS DEPENDING ON THE LIFE TIME YOU SET FOR IT. SO IT CAN LAST FOR YEARS
 This is the major diff. in your choice,

 If you want the idu to be remembered for long time, then u need to use cookies, else if u just want the website to recognize the user for this visit only then sessions is your man.

 hope it helps :)

 -- further explanation.

 Sessions is stored in a file your php server will generate, and to remember which file is for which user, php will also set a cookie on user browser that hole this session file id, so in his next visit php will read this file and reload session.

 now php by default clear sessions every interval, and also naming convention of session make it auto expire. plus browsers will not keep cookie that hold session id once closed/history cleared.

 its important to notice that nowdays browsers also support another kind of storage engines which are :-

 LocalStorage, SessionStorage, and other webdb engines that javascript code can use to save data to your computer to remember you. just open javascript console inside facebook for example and type "localStorage" enter. it will show you all variables fb use to remember you without cookies.
	A cookie is simply a short text string that is sent back and forth between the client and the server. You could store name=bob; password=asdfas in a cookie and send that back and forth to identify the client on the server side. You could think of this as carrying on an exchange with a bank teller who has no short term memory, and needs you to identify yourself for each and every transaction. Of course using a cookie to store this kind information is horrible insecure. Cookies are also limited in size.

	Now, when the bank teller knows about his/her memory problem, He/She can write down your information on a piece of paper and assign you a short id number. Then, instead of giving your account number and driver's license for each transaction, you can just say "I'm client 12"

	Translating that to Web Servers: The server will store the pertinent information in the session object, and create a session ID which it will send back to the client in a cookie. When the client sends back the cookie, the server can simply look up the session object using the ID. So, if you delete the cookie, the session will be lost.

	One other alternative is for the server to use URL rewriting to exchange the session id.

	Suppose you had a link - www.myserver.com/myApp.jsp You could go through the page and rewrite every URL as www.myserver.com/myApp.jsp?sessionID=asdf or even www.myserver.com/asdf/myApp.jsp and exchange the identifier that way. This technique is handled by the web application container and is usually turned on by setting the configuration to use cookieless sessions.

	SESSIONS ENDS WHEN USER CLOSE HIS BROWSER,

	COOKIES ENDS DEPENDING ON THE LIFE TIME YOU SET FOR IT. SO IT CAN LAST FOR YEARS
	This is the major diff. in your choice,

	If you want the idu to be remembered for long time, then u need to use cookies, else if u just want the website to recognize the user for this visit only then sessions is your man.

	hope it helps :)

	-- further explanation.

	Sessions is stored in a file your php server will generate, and to remember which file is for which user, php will also set a cookie on user browser that hole this session file id, so in his next visit php will read this file and reload session.

	now php by default clear sessions every interval, and also naming convention of session make it auto expire. plus browsers will not keep cookie that hold session id once closed/history cleared.

	its important to notice that nowdays browsers also support another kind of storage engines which are :-

	LocalStorage, SessionStorage, and other webdb engines that javascript code can use to save data to your computer to remember you. just open javascript console inside facebook for example and type "localStorage" enter. it will show you all variables fb use to remember you without cookies.