A more recent development in webcomponents is to use a compiler to create vanilla Javascript bundles at build time. Examples are Svelte https://svelte.technology and Stenciljs https://stenciljs.com.

Maybe that is something to consider when you get to the building chapter smilie
OK the reason is, run.sh is created with Windows line endings in the docker image if you check out with automatic lf->crlf conversion. One possible solution is to tell git not to convert line endings for *.sh files.

When cloning, do not checkout immediately (Tortoise: enable 'No Checkout' option)
Add a.gitattributes file with the following content to your empty, cloned working directory:

*.sh text eol=lf

Afterwards, check out (Tortoise: Switch/Checkout master)

Request for improvement: add .gitattribute file to the book's source repository. Should I send a PR for that?
I have the exact same problem. Indeed, sh does not see run.sh, although it is there in the filesystem. The container is fine and sh finds executables on PATH and manually added executables, but not run.sh.

I have opened a stackoverflow question http://stackoverflow.com/questions/43556722/sh-in-docker-image-does-not-see-executable
could you please also comment on the security issue?

Just two example discussions where oauth/openid in an iframe gets a verdict to be a serious security problem, so much that authorization providers apparently have started to forbid to run their authorization endpoint in an iframe:



The attack vectors are phishing (attacker shows authorization ui in iframe on phishing page) and clickjacking (described in oauth rfc), and the arguments sound solid to me.

The case that there is an openid draft that manages a session in an iframe is a different thing, since these iframes have no ui.

When discussing implicit grant on page 114 you say "The client sends its request to the authorization server’s authorization endpoint in the same manner as the authorization code flow, except that this time the response_type parameter is set to token instead of code ... The client can do this by using a full-page redirect or by using an inline frame (iframe) inside the page itself."

The last sentence confused me a bit, because the client does not use a redirect, only the server can do that. I think what is meant here is that the spa can request the authorization ui from the authorization endpoint by navigating to a different page (window.location) or by loading the authorization ui into an iframe.

The iframe option is pretty unclear to me though. The redirect that sends the token via front-channel would happen in the iframe. How can the spa in the page that hosts the iframe make use of the token?
In addition the security considerations of the rfc https://tools.ietf.org/html/rfc6749#section-10.13 seem to discourage the use of iframes for authorization UIs.

If iframe is a valid option, how does it work exactly? If not, maybe better don't mention it.
You recommend using service worker as a cache for the app's ui shell. For that, the classic http cache is also an option, even in pretty old browsers and absence or failure of js. Maybe a box which discusses pros and cons of both would be helpful. For a static ui shell I would go for classic caching, but stand to be convinced why service worker is better.
Dear authors,

while the book clearly describes how a browser application can receive an Oauth2 authorization token, a number of questions remain unsolved (or I missed that part).

- what is an acceptable practice for the SPA to maintain the access token? Google and oauth js libraries in Github simply store it in HTML5 local storage, which seems not a safe place at first sight. What are the exact risks of doing so and what are possible measures which still might make it acceptable to use local storage? If an application shows sensitive data, is it feasible at all to use an SPA with grant type token?
- if the access token should be short-lived (a few minutes?) and the client has no refresh token, does the resource owner have to re-grant every few minutes in such an SPA? Can that be avoided? Is there a way to keep the token valid exactly as long as the user interacts with the protected resource?
- my primary concern with local storage is the internet-cafe scenario: if stored locally, anyone can find my access token and use it after I have left the place

- if the client is a web application, then the client is the instance which has the means to access protected resources, not the browser. How does one ensure that the application client can only be used by the browser which started the conversation?

- if I decide to use grant type code with a web application client, how would an SPA look like that communicates via Ajax through the web application client? It seems the web application would be a sort of proxy which passes through the Ajax requests, adding access tokens and using refresh tokens. Is it possible to avoid that the web application client needs a session, to ensure cloud-like scalability? Where would the web application client (the proxy) hold the tokens and how would it identify the tokens it should add to an incoming request?

- an SPA makes Ajax requests to retrieve its data. If the data are protected, the service might want to redirect to an authorization page. In that case the SPA must switch from Ajax to going to a new browser location. How would you suggest to make that switch happen? If the Ajax response is a 302, then the browser follows the redirect to the new location and the response would be html instead of the expected data format (e.g. json or xml).

This sidebar is obviously wrong, the text says nothing about threads:

Do EJBs need to be thread-safe?
We are using JDBC for simplicity only because we have not introduced the EJB 3
Persistence API (JPA) in any detail yet. We don’t want to assume that you already
understand ORM. Using JDBC also happens to demonstrate dependency injection of
resources and the stateless bean lifecycle callbacks. In general, you should avoid using
JDBC in favor of JPA once you are comfortable with it.

Message was edited by: