A more realistic example storage

[mitar]

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

When trying to implement a storage for Fosite, it is hard to understand how to do it. Documentation is lacking (#25) and memory storage example is not realistic: it does not serialize/deserialize data, but just stores memory objects as-is.

Describe the solution you'd like

I would suggest that example memory storage does expected full serialization and deserialization of objects, just that it stores serialized value in memory instead of a database. Then it would be easier for implementor to see what has to be done in a new storage implementation.

Describe alternatives you've considered

This is just a first step towards better documentation and instructions which would help as well.

Additional context

One of initial goals/motivations of this project was that this library should be better how to store things at rest. But without a bit of help here, I do not think it is realistic for users of this library to really do so, and for example, not store sensitive data unencrypted into the database, just because they store the whole request as-is, including potential secrets in there.

For example, form data can contain client_secret (one can provide that even authorize endpoint, by mistake, and Fosite does not complain, and will probably store it as-is into the database) or password in resource owner flow. So storing request and form data directly could allow users of the library to store form data unencrypted.

A good example storage could help here.

[github-actions]

I am marking this issue as stale as it has not received any engagement from the community or maintainers in over half a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas how you could contribute towards resolving it;
• open a new issue with updated details and a plan on resolving the issue.

We are cleaning up issues every now and then, primarily to keep the 4000+ issues in our backlog in check and to prevent maintainer burnout. Burnout in open source maintainership is a widespread and serious issue. It can lead to severe personal and health issues as well as enabling catastrophic attack vectors.

Thank you for your understanding and to anyone who participated in the issue! 🙏✌️

If you feel strongly about this issues and have ideas on resolving it, please comment. Otherwise it will be closed in 30 days!