loopbackio / loopbackio/loopback-next

Allow middleware to redirect without the controller being involved.

Aperta
#6,894 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

feature REST
Lingua principale
TypeScript
Stelle
5.1k
Fork
1.1k
Merge medio
2g 21h
PR unite (30g)
27

Descrizione

## Suggestion

It would appear that today if some middleware logic wishes to send a redirect response, the controller must be aware of that and handle the redirection on behalf of the middleware. This seems a bit [incoherent](https://en.wikipedia.org/wiki/Cohesion_(computer_science)), as the controller is generally concerned with managing the resource defined by the REST endpoint, and not the needs of the middleware.

## Use Cases

Authentication. See [this example](https://loopback.io/doc/en/lb4/migration-auth-passport.html#configuring-authentication-endpoints-1). Why do I need special controller logic for `loginToThirdParty` there? If the middleware abstraction weren't leaking, I'd expect that I could just decorate any endpoint method of my controller with `@authenticate(STRATEGY_NAME)` and if the strategy requires redirection (e.g. OIDC), the user should be redirected to login/grant access, then redirected back to the endpoint in question. If I want to enable this behaviour today it would appear that I need this redirection logic for every single protected controller function that I write.

## Examples

One way to achieve this would be to follow the pattern that `AuthenticationActionProvider` uses [here](https://github.com/strongloop/loopback-next/blob/6a228264f3bb67af53fd74ebbf9439cab44fa286/packages/authentication/src/providers/auth-action.provider.ts#L86-L87), but instead of writing to setters that are bound to a binding specific to the Authentication namespace, write to some more generic binding that can be picked up and handled before the controller is ever called, subverting the need to call the controller entirely.

Another way might be to inspect the return value of the middleware. If it returns a `RedirectRoute`, redirect instead of calling the controller. I find this to be a cleaner option than injecting setters, but I can imagine this being more difficult to implement. As an aside, it'd be nice if controllers could do this as well, rather than requiring the `Response` object to be injected.

## Acceptance criteria

TBD - will be filled by the team.

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Direzione di ricerca

Inizia esaminando packages/authentication/src/providers/auth-action.provider.ts in corrispondenza delle righe indicate, quindi traccia il modo in cui vengono gestiti i risultati del middleware e l’invocazione del controller. Confronta gli approcci proposti basati sul binding e RedirectRoute; i criteri di accettazione dell’issue sono ancora TBD, quindi il team deve definire il comportamento previsto prima che l’implementazione possa essere considerata completata.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
typescript
Ambito
api, backend-api-design
Tipo di issue
Funzionalità
Difficoltà
5/5
Tempo stimato
Più di una settimana
Stato di attività
Ferma
Chiarezza
Da chiarire
Idoneità per principianti
25/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.