Clarification on Shiny

[gshotwell]

Thanks for the great resource, it was super great to see all of these frameworks in one place with at least one example apps. I'm one of the devs on Shiny, and just wanted some clarification on this sentence:

"Like many class B solutions, it lacks the features for complete web applications – authentication, authorization and sessioning."

Shiny is built on the same stack as FastAPI so there's a lot of ways to authenticate it. Our professional products also support authentication.

Shiny also has session objects which can be accessed by the application process. Depending on the authentication method this can also be used to change app behaviour based on the logged-in user.

So overall it seems pretty similar to Solara and Dash, which are both in class A. Can you provide more detail on what you mean by authentication/authorization or sessioning?

[metaperl]

Thanks for the great resource, it was super great to see all of these frameworks in one place with at least one example apps.

Yes, the Python ecosystem is amazing in this domain of pure python web apps.

Shiny is built on the same stack as FastAPI so there's a lot of ways to authenticate it. Our professional products also support authentication.

I see. Is it built on Starlette? Are there any examples of authentication and authorization?

Shiny also has session objects which can be accessed by the application process.

Noted.

Based on this discussion, the comments about lack of sessioning should be removed.

Do the authentication methods tie in with the session object? Meaning, that based on who authenticated the session object has info about that person that logged in?

Authorization is a trickly concept, especially when you get to single page apps which may not operate in the Flask/Django way of having discrete URLs for each action.

TODOMVC is great for some basics, but we definitely need a "Class A benchmark" which all pure-python-web-devs can provide to close the gap between TODOMVC (which exemplifies model-view-controller) and something more (to exemplify the requirements of a Class A system.

[gshotwell]

Yup, it's Starlette, ASGI and Uvicorn

https://shiny.rstudio.com/py/docs/deploy.html#other-hosting-options

Yes you can pass information on logins to the session object. So if you're hosting a shiny for python app on our paid products you can access session.user to get the user id. I think the same should be possible for other authentication flows, but it would be a bit context dependent.

[metaperl]

So if you're hosting a shiny for python app on our paid products you can access session.user to get the user id.

You mean it costs money to have access to session.user?

FYI, if I'm not mistaken, the way I drew my conclusions about Shiny was by looking at the Learn Shiny docs. I did not see anything about authentication or authorization there or sessions. So I think that is how I drew my conclusions, but I cant remember.

Putting a paywall on basic Class A functionality is a bit unappealing to me... I think Dash does a similar thing by only having SSO available for pay.

[gshotwell]

It doesn't cost money to access session.user, but to do this the authentication service needs to set HTTP headers to inform the user property. It's hard to be very specific here because it depends a bit on how auth is set up, but this is fairly similar to those other frameworks as far as I can tell.

That's a totally valid way to draw conclusions, and we probably should improve the docs on this point.

[metaperl]

Please direct any future discussion on Shiny for Python here - #32