A sequence action for stateful requests (HTTP sessions)

[GuerricPhalippou]

Feature proposal

Since middlewares are internally used and not exposed to developers, there is no possible way to implement stateful requests, as it was done with the express-session middleware before v4.

Current Behavior

The v4 complying solution would be a sequence action, but it doesn't exist yet in RestBindings.SequenceActions.

Expected Behavior

Have a sequence action that retrieves cookies information and make it available to the app via context and dependency injection

[bajtos]

@GuerricPhalippou thank you for opening the issue. For reference, here is our original discussion on StackOverflow: https://stackoverflow.com/q/52833380/69868

As I wrote on StackOverflow, I think that ideally, session handling should be implemented as a new Sequence action - see Sequence docs.

class MySequence {
  // skipping constructor with dependencies to be injected
    
  async handle(context: RequestContext) {
    try {
      // the following line is new
      const session = this.restoreSession(context);

      // the default sequence continues here
      const route = this.findRoute(context.request);
      const params = await this.parseParams(context.request, route);
      const result = await this.invoke(route, params);
      await this.send(context.response, result);
    } catch (error) {
      await this.reject(context, error);
    }
  }
}

The sequence action restoreSession should:

• check if there are any session cookies present in the request
• load the session if a cookie was provided, maybe create a new one otherwise?
• bind the session in our Context so that other places like controllers can receive the session via Dependency Injection

The v4 complying solution would be a sequence action, but it doesn't exist yet in RestBindings.SequenceActions.
Have a sequence action that retrieves cookies information and make it available to the app via context and dependency injection.

On of our design goals for LoopBack 4 was to make it easy for 3rd party developers to contribute extensions and thus keep the framework modular. IMO, session handling should live in a new module independent from @loopback/rest.

I am expecting there will be many users looking for HTTP session support, therefore it makes sense to me to keep the session extension inside loopback-next monorepo.

@GuerricPhalippou would you like to contribute this session extension yourself? I am happy to help you along the way.

[GuerricPhalippou]

@bajtos I'm sorry but I dropped Loopback 4 and rollbacked to Loopback 3 since the features I need will not be implemented in a near future. Plus, my employer does not allocate time for open source contribution and I feel like it takes time to dive in Loopback 4 implementation and provide a solution that covers everyone's use cases.

[bajtos]

@GuerricPhalippou Thanks for letting us know about your situation. I wish you good luck in your projects and hope to see you here again in the future, when LB4 comes closer to LB3 in terms feature parity :)

[lazaro9318]

@bajtos I want to contribute to create the new action, but actually I need a quickly solution for create the session and retrieve the sessionID, Could you please help me with that?

[bajtos]

@lazaro9318 see #1863 (comment)

[mrmodise]

@GuerricPhalippou i resolved this in the interim by using Lerna to create another Loopback 4 app package that uses Express server plus Request to get the JSESSIONID from the cookie. I then store this on Redis for any subsequent requests. I will be happy to share the solution for anyone who is deep into Loopback 4 that it’s impossible to rollback

[malek0512]

I'm interested by a solution for this feature.
@mrmodise Can you share alternative ?
Thanks in advance.

[L-Luciano]

Any news ?