Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request]: Be able to implement an async Custom Storage #1929

Open
stemlaur opened this issue Apr 25, 2024 · 2 comments
Open

[Feature Request]: Be able to implement an async Custom Storage #1929

stemlaur opened this issue Apr 25, 2024 · 2 comments

Comments

@stemlaur
Copy link

Is your feature request related to a problem? Please describe.

Currently, the library allows to implement a custom storage, but it is limited to synchronous implementation, a developer should be able to implement an async custom storage returning Promises.

Describe the solution you'd like

It would be awesome to be able to create a custom storage like this one:

import { AbstractSecurityStorage } from 'angular-auth-oidc-client';

@Injectable()
export class AsyncStorageService implements AbstractSecurityStorage {

  read(key: string): Promise<any> {
    return await ...;
  }

  write(key: string, value: any): Promise<void> {
    await ...
  }

  remove(key: string): Promise<void> {
    await ...
  }

  clear(): void {
    await ...
  }
}

The library should check if the return object is a promise and await it if it is.

@jhpetersen
Copy link
Contributor

Same same for me: i would like to store security data within a local SQLite db, but as all read/write operations are asynchronous, it is impossible to implement a custom storage provider for that use case.

Furthermore the hasStorage() method within BrowserStorageService could be problematic if the provided custom storage provider does not rely on default Storage interface..

@jhpetersen
Copy link
Contributor

I would have liked to propose a PR, but just realized that synchronous calls to StoragePersistenceService read/write/remove/clear methods spreads over a lot of services/classes and these in turn are also synchronous methods, and so on.

So i assume implementing an async storage provider will result in huge effort to convert most parts of this library to async code, and thus will be a major/breaking change.

So the question to the creators/maintainers of this library: is this somehow on the roadmap?
(is there any roadmap at all? 🤔 😉)
Or do you see any possibility how to achieve this with less effort / limited changes?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants