Static-web-apps: Authentication Debugging / make /.auth/* available in local function app

[martinmeeser]

I really like static web apps! All I need is there - kind of. Easy deploy. Very secure (Auth/Reverser Proxy, SLL Certificates)

What I am struggling with right now is:
I can not debug the authentication process at all.

I am running the live server for static content, also running the local function app.

But route ./auth is not present.

However it should and provide some useful users.

So that I can debug with some user information.

Currently I feel like falling back to a normal web app, but that is also a lot of work with auth and certs and reverse proxy.

[mkarmark]

@martinmeeser sorry to hear about your frustrating experience. Just to clarify so that I can try to help, are you trying to hit the /.auth endpoint on your static web app or your function app?

[martinmeeser]

I have followed the documentation:
https://docs.microsoft.com/en-us/azure/static-web-apps/

Especially the part:
https://docs.microsoft.com/en-us/azure/static-web-apps/local-development

I am using live server to serve the static content.
I have also started the Azure Functions Core tools.

Breakpoints get hit, awesome!

I also followed the documentation with the routes.
I have added

a href="login/facebook">Login

to the index.html.

At the deployed "prod" site, I can follow this link to facebook login screen.

At my local site. it says
"Cannot GET /login/facebook"

The very best solution IMHO would be the local function app just mocking the auth provider, so that there is a seamless local (debugging) experience.
Maybe with some local json to get some positive and negative logins.

The follow-up problem is:
How to access the provider's user data in the function app locally?

Another solution would be to reroute the local login to an actual real auth provider, and remove that in the deployment branch (but I am not sure how to achieve this right now, and I see a good risk of screwing the prod env, up)

Another idea I have is that I just login at the real thing and take a look at all the url-params, the body and the headers.
Last but not least I have read that I can remote debug functions with Visual Studio 2019 so I could give that a shot (but I am on Linux now)

As you can see, if I could just debug the whole thing locally seamlessly - that would be huge (from my point of view)!

But let me emphasize again, that I like it very much that everything is in one place (static content, api, security and auth, custom certs ...)
It is my personal buy in on Azure!

Kind regards
Martin

[anthonychu]

@martinmeeser We're working on this! In a month or two, we'll make available a local CLI that will emulate some of this logic in the cloud. We plan to support many of the routing rules and the auth endpoints. Current plan is to support a simulated login screen at .auth/<provider>/login where you can select what provider, user, and role(s) you'd like to log in as and the .auth/me endpoint as well as the function headers will include the information.

[martinmeeser]

sounds great, looking forward to

[tcc-sejohnson]

@martinmeeser

In the meantime, as it seems this still isn't out (unless I've missed something), it took me about fifteen minutes to set up msw to mock requests to all of the .auth endpoints. It's been a great stopgap!

[martinmeeser]

I have also shifted to a classic webapp. :-( However will keep an eye on it, maybe the next project ...

[enricobertolotti]

@anthonychu do you have an update on this? I love the static web apps system, but not having the auth implementation for dev environments is a bit of a dealbreaker :/

[anthonychu]

Yes we have a Static Web Apps CLI here: https://www.npmjs.com/package/@azure/static-web-apps-cli

We’re putting some final touches on it before we declare it available for public preview, but you can try it out now.

It includes a local auth emulator that lets you simulate login as any user/provider.

We’ll have better instructions for it soon. Also check out this stream where we demo how it works: https://youtu.be/xEYQBPo11iI

[enricobertolotti]

@anthonychu thank you so much this was exactly what I was looking for!