Angular 5登录用户对象最佳缓存存储位置咨询

Hey there! Let’s break down which storage option makes the most sense for your scenario, since you’re already using localStorage but want to ensure you’re making the best choice for your large user object.

First, let’s compare the three options you mentioned: #

1. localStorage #

• Stick around for good: This data stays saved even when the user closes their browser (until either your app clears it or the user manually deletes it).
• Plenty of space: It has a ~5MB limit, which is more than enough for even a large user object.
• Accessible everywhere: All tabs/windows of your app (same origin) can access this data.
• Your current setup: You’re already doing the right thing by serializing the object (like localStorage.setItem("user", JSON.stringify(loginResponse.user))) since localStorage only stores strings.

Why it works for you: If you want users to stay logged in across browser sessions (think "remember me" functionality), this is perfect. It also keeps the user details intact after page reloads, which is exactly what you need.
Watch out: If your user object has sensitive data (like access tokens, personal info), localStorage is vulnerable to XSS attacks—malicious scripts injected into your site could read this data.

2. sessionStorage #

• Temporary only: This data gets cleared as soon as the user closes the tab or browser window.
• Same space as localStorage: ~5MB, so no issues with large user objects here either.
• Tab-specific: Only the tab where you stored the data can access it—new tabs won’t see it.

Why it might be better: If you don’t need users to stay logged in after closing their browser, this is more secure than localStorage. It still retains data when the page reloads in the same tab, so you get that benefit without long-term persistence risks.
Downside: No cross-tab access, and no persistence across browser sessions.

3. Cookies #

• Flexible persistence: You can set them to expire after a certain time or only last for the current session.
• Super small limit: Only ~4KB per cookie. This is a dealbreaker for your large user object—you’ll almost certainly hit this limit if you try to store the whole thing.
• Sent with every request: Cookies are included in every HTTP call to your server, which adds unnecessary overhead unless you actually need that data on the server with every request.
• Security perks: You can mark cookies as HttpOnly (so JavaScript can’t access them, blocking XSS risks) and Secure (only sent over HTTPS).

Why it’s not ideal for the full user object: The 4KB limit makes it impossible to store a large user object here. You could use it for sensitive tokens, but not the full details.

My Recommendation for Your Use Case #

Given that you have a large user object and need it to persist after page reloads:

• If you want "remember me" functionality: Keep using localStorage, but split out sensitive data. Store non-sensitive user details (like name, profile info) in localStorage, and put any sensitive tokens in an HttpOnly cookie instead to keep them safe from XSS.
• If you don’t need cross-session persistence: Switch to sessionStorage. It still works across page reloads in the same tab, and reduces the risk of sensitive data hanging around longer than needed.
• Skip cookies for the full user object: The 4KB limit is too restrictive here. Use cookies only for small, sensitive pieces like tokens.

One final tip: Always validate and sanitize any data you pull from storage before using it in your app—never trust stored data completely, even if your app wrote it!

内容的提问来源于stack exchange，提问作者RoHaN