Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Comments on Storing input from different frontend webpages of a multi page contact form

Parent

Storing input from different frontend webpages of a multi page contact form

+0
−3

I consider to create a multi page contact form in which there is one backend page but about 5 front-end pages (stage 1-5). Pages 1-4 are input pages and page 5 is for a submit button and a success message.


I understand that I can save the data of each stage (before the form submit in stage 5) in either of the following:

  • Cookie
  • LocalStorage
  • SessionStorage

How should I determine which of these Web browser data storages would best fit my need?

History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

2 comment threads

How would one determine anything? (4 comments)
Application type (2 comments)
Post
+3
−0

Cookies vs Local Storage vs Session Storage.

Cookies

  • Has different expiration dates (both the server or client can setup expiration date).
  • Cookies themselves can specify which pages from which domains can access them, or restrict access to pages having the same secure origin.
  • Client-side Javascript can be denied access to a cookie value by the cookie's HttpOnly attribute, even if the domain/path-based access policy would otherwise have allowed it.
  • Data are transferred on each HTTP request.
  • The max size for Cookies are 4KB.

More about Cookies.

Use document.cookie to create Cookies in JavaScript.

Local Storage

  • Has no expiration date.
  • Part of the browser-side "Web Storage". A web server is not involved in the function of the "Web Storage" mechanism.
  • Access to data stored in "Web Storage" is strictly on a "same origin" basis. Only pages loaded from URLs that share the same origin (scheme, host and port) have access to the same data.
  • Data are not transferred on each HTTP request.
  • The max size for Local Storage is 5MB.

Use window.localStorage to access the Storage.

Session Storage

  • Data is gone when you close the browser tab.
  • Part of the browser-side "Web Storage". A web server is not involved in the function of the "Web storage" mechanism.
  • Access to data stored in "Web Storage" is strictly on a "same origin" basis. Only pages loaded from URLs that share the same origin (scheme, host and port) have access to the same data.
  • Data are not transferred on each HTTP request
  • The max size for Session Storage is 5 to 10 MB.

Use window.sessionStorage to access the session Storage.

This were some facts about Cookies & Local Storage & Session Storage. You can now choose which will fit your cause but likely it will be Local Storage but it is also your opinion.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

SSL? (10 comments)
SSL?
elgonzo‭ wrote almost 3 years ago · edited almost 3 years ago

Wait... are you saying that a page using the web storage APIs cannot access some web resource via HTTPS? Your explanation almost makes it sound so. I guess, it would be less ambiguous to simply state that cookies are part of the HTTP protocol, whereas the web storage APIs themselves are not part of an transport protocol (the web storage APIs are concerned about data storage on the client only, and not concerned at all about data transmission between browser/client and server).

Kevin M. Mansour‭ wrote almost 3 years ago

No. Web storage is per origin (per domain and protocol). All pages, from one origin, can store and access the same data.

elgonzo‭ wrote almost 3 years ago · edited almost 3 years ago

Yeah, but how did you go from this to "no support for SSL"? Again, the web storage APIs are not concerned about transport, so it is a mystery to me what you meant by writing "no support for SSL".

Kevin M. Mansour‭ wrote almost 3 years ago

I meant Web storage APIs are accessible from the client-side only (web servers can't access them directly). Also since they are a front-end tool, they have no SSL support.

elgonzo‭ wrote almost 3 years ago · edited almost 3 years ago

But that you already said that with "client-only". If it is about being a front-end tool, what has that to do with SSL? How is mentioning SSL even relevant in this context? Following your argument, you could equally say "no support for HTTP" or "no support for TCP/IP" with the same relevance. In my opinion, the mention of "no support for SSL" is not just superfluous, it is potentially misleading.

Kevin M. Mansour‭ wrote almost 3 years ago

Hmm? If you see that no support for HTTP is more clearer. so, you can edit my answer then.

elgonzo‭ wrote almost 3 years ago · edited almost 3 years ago

I would suggest removing this line entirely, as it does not convey any useful information in my opinion, and might mislead readers as i insinuated in my first comment. What do you think?

Kevin M. Mansour‭ wrote almost 3 years ago · edited almost 3 years ago

I think it is useful. But you could edit it.

Update:

Maybe you could delete it.

elgonzo‭ wrote almost 3 years ago

Alright. My edit is pending in the review queue. I have added a little bit about access control which is significantly different between cookies and web storage. And i just noticed that i omitted a bit about the cookie access control, as it is not only domain/path based, but also includes scheme-based access control. After my edit passes the review queue, i'll make another little edit to add this... :-)

Kevin M. Mansour‭ wrote almost 3 years ago

As it improves the post. I have approved it. :)