examples: Add single page (React) app with OAuth #31534
Conversation
|
cc @mmorel-35 this will need the dependatool npm update we discussed |
|
/docs |
|
Docs for this Pull Request will be rendered here: https://storage.googleapis.com/envoy-pr/31534/docs/index.html The docs are (re-)rendered each time the CI |
|
requires #31499 |
phlax
force-pushed
the
examples-oauth-react
branch
3 times, most recently
from
be659e9
to
34c48dc
Compare
I see, I'm going to provide a PR on toolshed before the end of the week to fix this. |
phlax
force-pushed
the
examples-oauth-react
branch
from
34c48dc
to
52d0cd6
Compare
i made an attempt at it here envoyproxy/toolshed#1374 - it needs some tests, cleanups and to be tested yet |
phlax
changed the title
phlax
force-pushed
the
examples-oauth-react
branch
from
52d0cd6
to
7f60e27
Compare
phlax
force-pushed
the
examples-oauth-react
branch
2 times, most recently
from
3c66725
to
4de9997
Compare
phlax
force-pushed
the
examples-oauth-react
branch
2 times, most recently
from
9b90c11
to
5fcc6a6
Compare
|
ill try and get to this today - been a bit snowed under with release stuff |
phlax
force-pushed
the
examples-oauth-react
branch
from
573267e
to
70fd8d4
Compare
|
@htuch this should be ready for another review, apologies for force-push, commits were preserved after rebase |
| :ref:`forward_bearer_token <envoy_v3_api_field_extensions.filters.http.oauth2.v3.OAuth2Config.forward_bearer_token>` | ||
| means the provided access token will be forwarded to upstreams proxied by Envoy unless explicitly excluded. | ||
|
|
||
| This can be avoided by disabling the OAuth2 filter with |
| .. warning:: | ||
| Setting | ||
| :ref:`forward_bearer_token <envoy_v3_api_field_extensions.filters.http.oauth2.v3.OAuth2Config.forward_bearer_token>` | ||
| means the provided access token will be forwarded to upstreams proxied by Envoy unless explicitly excluded. |
There was a problem hiding this comment.
| means the provided access token will be forwarded to upstreams proxied by Envoy unless explicitly excluded. | |
| means the provided access token will be forwarded to any cluster / upstreams proxied by Envoy for this HTTP filter chain. In general, upstreams should be trusted in this scenario. If untrusted upstreams are present, care will need to be taken to not only disable the OAuth2 filter on a per-route basis but to also remove sensitive cookies with bearer tokens, etc. This scenario is outside the scope of this sandbox. |
There was a problem hiding this comment.
i may be wrong but i think the important thing is removing the cookie/header - not sure that enabling/disabling the oauth filter would achieve this or help - besides in this situation you would need to disable it for given upstreams anyway (whether by pass_through or disabling the filter) just to get it to work correctly
ive updated on this basis
|
|
||
| A dummy "Myhub" backend is provided with a minimal OAuth provider and API for use in the example. | ||
|
|
||
| Setup is provided to :ref:`build and update the app for production use <install_sandboxes_single_page_app_step_production_build>`, |
There was a problem hiding this comment.
What does production mean when we're using a dummy OAuth backend as per previous paragraph?
There was a problem hiding this comment.
it means not served by a dev backend - static assets essentially - i added gzip/tls as pointers to what else you might add
There was a problem hiding this comment.
its hard not to call it production becase that is what js/node calls it when you build the assets rather than serve them
eg - it reads .env.production in that circumstance
| .. warning:: | ||
| Envoy's OAuth implementation defaults to triggering the OAuth flow for all paths on the endpoint. | ||
|
|
||
| This can readily trigger an OAuth flood as assets are requested, and doom loops when the OAuth flows fail. |
There was a problem hiding this comment.
Not sure I fully follow - shouldn't the access token creation obtain sufficient scope to be able to reuse the OAuth cookie in future accesses to other paths?
There was a problem hiding this comment.
if you dont restrict what triggers the oauth flow then its triggered on the assets
this can cause redirect loops which take over the client (browser) machine and flood the proxy
not knowing this when i started i really struggled to get anything working so i think we need to say something - here im trying to highlight the strategy/config used to avoid that (ie inverse matching)
Signed-off-by: Ryan Northey <ryan@synca.io>
Co-authored-by: htuch <htuch@users.noreply.github.com> Signed-off-by: phlax <phlax@users.noreply.github.com> Signed-off-by: Ryan Northey <ryan@synca.io>
Signed-off-by: Ryan Northey <ryan@synca.io>
Signed-off-by: Ryan Northey <ryan@synca.io>
Signed-off-by: Ryan Northey <ryan@synca.io>
Signed-off-by: Ryan Northey <ryan@synca.io>
Signed-off-by: Ryan Northey <ryan@synca.io>
phlax
force-pushed
the
examples-oauth-react
branch
from
70fd8d4
to
6c1c926
Compare
|
Guess I should have said - my approval is typescript-specific and continues to apply so long as no typescript files are changed. I'm not going to re-approve since other reviewers are still reviewing other stuff, but feel free to assume from here on that the typescript is already reviewed. |
|
@htuch landing this to get it in - we can follow as required |
|
I think my main concerns are addressed. I haven't walked through the Github production parts but the core guidance seems generally correct. |
Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]