feat: add new local auth UX

[manekinekko]

(work in progress)

• sync with localStorage
• clear form
• set provider from URL
• create Cookie

Closes #47
cc @anthonychu @annaji-msft

[anthonychu]

Wow. This is way nicer than I imagined. 😍

I wonder if the provider dropdown is redundant. Perhaps it should just use what's in the URL.

Also keep in mind that it's possible that the URL can be rewritten by a routing rule. There'll also be more providers supported in the future via OpenID Connect integration (they can use any name).

[manekinekko]

I am wondering how can we get the provider if the route is being rewritten to something like:

{
      "route": "/login",
      "serve": "/.auth/login/github"
}

If we can't infer the provider from the URL:

• Should we show the providers list in this case and let the developer choose?
• Unless we can ask the Route Engine to provide this info for us, server-side and prepopulate the UI before serving it.

WDYT?

[anthonychu]

I don't think I know enough how the routing will work. The way I picture it in my head is that the routing code runs like a piece of middleware in the proxy's request pipeline. That rule would cause it to rewrite the URL to /.auth/login/github before the auth page is handled, so the page will "see" the rewritten path instead of the original path.

[manekinekko]

So maybe it would be useful to let the CLI knows what was the original route, when calling the routes engine.

Here is how I see it:

swa start -> 
  routes config -> 
  call routes engine -> 
  build internal routing model (original route, new route) -> 
  start swa proxy

When user requests /login:

client -> 
  swa proxy -> 
  parse URL -> 
  check URL with route model -> 
     if .auth/login/<provider>, 
         extract provider -> 
         hydrate html auth page -> 
  swa proxy -> 
client

[manekinekko]

Updated UX

Auth data is cached and keys are hashed by provider name:

[anthonychu]

This is awesome. Thanks!

Is returning the info from /.auth/me and adding the x-ms-claims-principal header for function app part of this PR or will it be a separate one?

[manekinekko]

I'm planning on migrating /.auth/me, /.auth/logout and /.auth/purge/** in this PR as well.

However, when requesting /.auth/me (example: https://githubadge.staticweb.app/.auth/me), I don't see x-ms-claims-principal in the response headers. Do you have an example or docs on how to set this header?

click to show logs

➜ curl https://githubadge.staticweb.app/.auth/me -v --cookie "StaticWebAppsAuthCookie=xxx"
> GET /.auth/me HTTP/2
> Host: githubadge.staticweb.app
> User-Agent: curl/7.64.1
> Accept: */*
> Cookie: StaticWebAppsAuthCookie=xxx
>
< HTTP/2 200
< content-length: 224
< content-type: application/json
< date: Sat, 30 Jan 2021 21:35:15 GMT
<
{
  "clientPrincipal": {
    "identityProvider": "github",
    "userId": "59cd31faa8c34919ac22c19af50482b8",
    "userDetails": "manekinekko",
    "userRoles": [
      "anonymous",
      "authenticated"
    ]
  }
* Connection #0 to host githubadge.staticweb.app left intact
}* Closing connection 0

[anthonychu]

However, when requesting /.auth/me (example: https://githubadge.staticweb.app/.auth/me), I don't see x-ms-claims-principal in the response headers. Do you have an example or docs on how to set this header?

/.auth/me doesn't need the header. The header I'm referring to is when a user is logged in, all http requests to functions should contain the x-ms-claims-principal header.

[manekinekko]

Oh! That's something we already do. See: https://github.com/Azure/static-web-apps-cli/blob/main/src/proxy.ts#L142

Is this working as expected or is it broken?

[anthonychu]

It was missing when I tried it yesterday with this PR. I'm using this app that has a function that dumps out the headers: https://github.com/anthonychu/swa-cli-js-sample

[manekinekko]

I am tracking this in issue #63

[aaronpowell]

Just tried this out and I've hit the following error:

[ swa] auth> GET http://localhost:4242/app/.auth/login/aad
[auth] [Error: ENOENT: no such file or directory, open '/home/aaron/code/github/static-web-apps-cli/dist/auth/index.html'] {                                                                      [auth]   errno: -2,                                                                                                                                                                               [auth]   code: 'ENOENT',
[auth]   syscall: 'open',
[auth]   path: '/home/aaron/code/github/static-web-apps-cli/dist/auth/index.html'                                                                                                                 [auth] }

When I look at the output in the dist folder I see this:

What you'll notice is that I have dist/auth/auth, and it's in that folder that index.html resides, whereas it's expected to be at dist/auth.

It's a matter of changing the npm script to:

"copy-assets": "cp -r ./src/auth/ ./dist"

But I thought there was a way to include "random files" in the output of a TypeScript compilation step...

[aaronpowell]

Next up - found myself with an invalid redirect:

[ swa] auth>> GET http://localhost:4242/app/.auth/logout
[ swa] {
[ swa]   "status": "302",
[ swa]   "content-type": "application/json",
[ swa]   "location": "http://localhost:8080undefined",
[ swa]   "set-cookie": [
[ swa]     "StaticWebAppsAuthCookie=deleted; Domain=localhost; Path=/; Expires=Thu, 01 Jan 1970 00:00:00 GMT"
[ swa]   ],
[ swa]   "access-control-allow-origin": "*",
[ swa]   "access-control-allow-methods": "GET,OPTIONS",
[ swa]   "access-control-allow-credentials": "true",
[ swa]   "date": "Wed, 03 Feb 2021 04:34:49 GMT",
[ swa]   "connection": "close",
[ swa]   "transfer-encoding": "chunked"
[ swa] }

Note the location header is "http://localhost:8080undefined", so somehow it's appending something invalid on it (not sure if that's my end or not).

[aaronpowell]

Yep, can confirm that like @anthonychu I'm not seeing it on this branch

Edit: actually, it's now working. I think it might be a bit flakey on whether it adds the header or not.

[manekinekko]

@aaronpowell the issue that Anthony reported should have been fixed by 0bafc54

[manekinekko]

@anthonychu @aaronpowell I am planning to merge this PR today.

[anthonychu]

Sorry haven't had a chance to test the latest changes. Yes please merge! Thanks.