Without having the full context of the interim meeting, this feels really off to me. I see the need for making this configurable, but I have doubts about using HTML elements for this purpose.
As far as I understand, this mechanism is supposed to be used for modern frontends (Angular, React, …). Having to add variables to the index.html in these applications is likely to conflict with their development paradigms. It would be much easier to add these variables to the environment file, so you can differentiate between dev and prod when necessary. Additionally, querying the DOM for API endpoints sounds like a lot of trouble. I don’t think that injection is that big of a risk, but I might be wrong (I’m sure someone said that about the base tag as well). However, using DOM APIs like this will cause headaches for server-side rendering, where these DOM APIs are typically not available (e.g., https://stackoverflow.com/questions/62896223/is-there-a-way-to-access-dom-serverside). Kind regards Philippe — Pragmatic Web Security Security for developers https://pragmaticwebsecurity.com/ > On 15 May 2021, at 17:35, Filip Skokan <[email protected]> wrote: > > Hello Vittorio, Brian, everyone > > This is a followup to my feedback in the TMI BFF interim meeting on April > 26th where I mentioned I'd bring this to the list for discussion. > > I proposed an alternative to using fixed endpoint locations and/or discovery. > HTML <meta> Tags <https://www.w3schools.com/tags/tag_meta.asp>. > > These would be in the returned page HTML's head tag, e.g. > > <meta name="oauth-bff-token" content="/api/bff-token"> > <meta name="oauth-bff-sessioninfo" content="/api/bff-sessioninfo"> > > The javascript SDK handing TMI BFF would know to look for these defined meta > tags to source the location of the different endpoints. I think this could be > the primary place an SDK would look at as it doesn't require any upfront > external requests. > > For the SDK this is as simple as > > var bffTokenPath = > document.querySelector('meta[name="oauth-bff-token"]').content; > > If this was the only mechanism defined by the document (to be bashed) I think > it can save the group a lot of time defining a client discovery document > which would be otherwise needed. If discovery as an alternative solution is > indeed inevitable, it can be a second in line mechanism the javascript SDK > would know to use. > > As discussed in the interim, a well known set of endpoints (or even a single > root client discovery document) might not always be available for control to > the webpage depending on where and how it is hosted, on the other hand the > HTML it serves always, I hope, is. > > Best, > Filip Skokan > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
