digitalfortress-tech / localstorage-slim Goto Github PK

I am trying to set the secret key from environment variable but I cannot do that.

// env
REACT_APP_LSKEY=123456789101112

//global setting
let key = Number(process.env.REACT_APP_LSKEY); //converting string to number
ls.config.encrypt = true;
ls.config.secret = key;

NOTE: I tried using secret key as string, still same issue hence I converted it into NUMBER.

//setting data in local storage
ls.set("foo", { bar: "baz" });

//getting data from local storage
let key = Number(process.env.REACT_APP_LSKEY);
let lsData= ls.get("foo", { secret: key });
console.log(lsData) // o/p: (empty)

If I set ls.config.secret = 50 then it is working fine but I want my secret key from env variable. Please help. Thank You.

A small question, does localstorage-slim support Server Side Rendering with NextJS? It works fine in development but I'm not sure about production.

Not a bug, a feature request.

Expected Behavior

It'd be nice to be able to use sessionStorage instead of localStorage in certain cases. Obviously localStorage should remain the default, but some way to configure this module would be useful.

Current Behavior

localStorage is always used.

Possible Solution

ls.config.storage = sessionStorage

ls.get('...') // use as normal, but will now read/write from `sessionStorage` instead

The nice thing about this is it'd allow for setting storage to other values with the same interface too - which could be useful for testing or for writing a low-level wrapper for localStorage or sessionStorage.

Context

Not having this means we get lots of nice features for using localStorage like better type-safety, rich object storage, and encyrption (also ttl/expiry, although obviously that's less of a concern for sessionStorage), but we have to use the raw API or find a similar library for sessionStorage. Given the tiny change that would be needed in this library to support sessionStorage, it seems worth doing.

What happened?

If one sets the storage option as sessionStorage in localoptions object it will be ignored and localStorage will be used instead.

Example:

ls.set("testItem", "123", {storage: sessionStorage});

It will save testItem in localStorage and not in sessionStorage. It can be observed on browser dev tools.

Also, when retrieving data, the library also ignores the storage option:

ls.get("testItem", {storage: sessionStorage});

It will retrieve the object not only in sessionStorage but also in localStorage. Not sure if the last behavior is intended though.

I provided a codepen project that shows both local and session behavior.

Affected version

v2.7.0

Reproduction URL

https://codepen.io/gurgelff/pen/OJdoyxr

How to reproduce?

1 - Go to the provided codepen link
2 - Write some value in input field, like 123 (the code is already set to use sessionStorage in localconfig object).
3 - Notice that "Get from sessionStorage (native API):" returns nothing from SessionStorage.
4 - Notice also that both session and local storage using the library return some values, even though the saved value is only present in session, and not in localStorage.

Browsers

Firefox, Brave

Relevant log output

No response

Additional context

On Codepen, when using global config the issue seems resolved. But a localconfig scope is something useful that needs to be solved.

There is also an issue when used in Angular, that even with a global config it still doesn't use sessionStorage, but that is a matter for another issue.

What happened?

I'm using the library in a cross-origin iframe while having third-party cookies disabled in Chrome.

In this situation, attempting to access the localStorage global variable results in the following exception: Uncaught DOMException: Failed to read the 'localStorage' property from 'Window': Access is denied for this document.

This library does not catch this exception. The fallback to memory store is never reached, because that is only enabled on an exception during localStorage.getItem(), which is never reached. Furthermore, isInit is set to true before the exception is thrown, causing storage to be undefined, resulting in subsequent exceptions such as Cannot read properties of undefined (reading 'getItem').

Affected version

Latest

Reproduction URL

https://codepen.io/niketpathak/pen/WNMKzoJ

How to reproduce?

Can be reproduced with the default Codepen while having third-party cookies disabled in Chrome. Typing something into the text field will raise errors in the browser console, and the value never makes it into the storage.

Browsers

Chrome

Relevant log output

No response

Additional context

No response

If the value is a string i am getting this error on ls.get using the package as browser context
Uncaught SyntaxError: Unexpected token e in JSON at position 0

Browser: Version 96.0.4664.93 (Official Build) (64-bit)
OS: windows 10

NB: I am using the value as a string with double quote

Could you add a feature to allow for a callback function to be passed into the set() method, and this callback would be fired when the ttl is reached?

Thanks
Justin

What happened?

When a key's value pre-exists as a string or has been previously set using the localStorage.setItem() method in local storage, a JSON parsing error arises upon invoking the ls.get() method.

Affected version

Latest

Reproduction URL

https://jsfiddle.net/j3qhtv28/5/

How to reproduce?

1. Go to the provided reproduction link
2. Click on 'Console'
3. See the error

Browsers

Chrome

Relevant log output

Uncaught SyntaxError: Unexpected token 'd', "d" is not valid JSON
    at JSON.parse (<anonymous>)
    at <anonymous>:1:6

Additional context

I observed that this issue was addressed in the commit. Do you plan to merge it into the main branch soon? If not, I'm willing to submit another request to expedite the fix, as it's crucial to resolve this promptly. This is a common scenario many front-end developers might encounter when launching a new app on the default port, especially if there's a residual "token" value in the local storage not set by the ls Object. Addressing this will prevent potential confusion.

Expected Behavior

The supportLS function should return false when a browser doesn't support localstorage.

Current Behavior

The supportLS function always return true, as the hasLS = true assignment happens after the try/catch block, which overwrites the value of hasLS when it is false.

Steps to Reproduce (for bugs)

Not provided, but bug is obvious by looking at the code.