📝 [Proposal]: Get session by its ID

[gandaldf]

Feature Proposal Description

Hello, I would like to propose a modification to the "middleware/session" package for v3. I think it would be quite useful to have a function that retrieves a specific session (using its ID). This way, developers would be given the opportunity to create a session manager, for instance, when I want to show my user information about their active sessions so they can decide which ones to invalidate.

If I may go further, I would even suggest renaming the function:
func (s *Store) Get(c *fiber.Ctx) (*Session, error)
to:
func (s *Store) Current(c *fiber.Ctx) (*Session, error)
because, well, the function actually creates or returns the current session; this way we would have the possibility to have a function:
func (s *Store) Get(id string) (*Session, error)
that returns the session by its ID.

I know this would be a quite significant breaking change, but it would also be very quick to fix.
Alternatively, we could opt for:
func (s *Store) GetByID(id string) (*Session, error)

What do you think?
I know that @sixcolors is quite involved with the development of the session-related code, and I would also like to get their opinion.
If needed, I would be happy to contribute to the necessary changes.

Alignment with Express API

No conflict with the Express.js API.

HTTP RFC Standards Compliance

No modification to the HTTP RFC standards.

API Stability

Depending on the type of function naming chosen, there could be breaking changes with v2, but they would be very quick to fix.

Feature Examples

func (s *Store) Get(id string) (*Session, error)
or:
func (s *Store) GetByID(id string) (*Session, error)
instead of:
func (s *Store) Get(c *fiber.Ctx) (*Session, error)
which could be renamed to:
func (s *Store) Current(c *fiber.Ctx) (*Session, error)

Checklist:

• I agree to follow Fiber's Code of Conduct.
• I have searched for existing issues that describe my proposal before opening this one.
• I understand that a proposal that does not meet these guidelines may be closed without explanation.

[sixcolors]

I agree; it is indeed useful. I'm currently working on a re-write. The only potential issue I see is that with the changes I'm making to transition to a middleware handler-based session and this proposal, there may be a risk of collisions. I'll strive to do this effectively to minimize unintended effects for developers.