I wrote this a short while ago http://simonh1000.github.io/2016/05/phoenix-elm-json-web-tokens/
On Wednesday, 6 July 2016 21:48:58 UTC+2, Erik Lott wrote: > > Yup, I understand passing down config (context) data down through the > update methods so they can be used in http requests. > > What's not clear to me is how you are using this technique in terms of > authentication. BTW: I'm generally a systems & server dev, so I'm likely > bringing that baggage with me. > > Here are some things that are not clear to me: > > 1. Digging through elm app source code, I often see a "Maybe > currentUser" field stored directly on the root model, and I that's fine. > Let's say I also have a nested LoginComponent for my UI, and this > component > does not have access to that root model (this is sort of obvious). When a > user uses this component to successfully authenticate themselves (the > LoginComponent makes the http request with the server), how am I then > communicating a successful login back up to the root model? Should the > LoginComponent directly return some data from it's update method - like > this > > <https://www.brianthicks.com/post/2016/06/23/candy-and-allowances-parent-child-communication-in-elm/> > ? > 2. If a nested component receives an 401 response back from the API, > how should I then propagate that response back up to the root so that the > current user can be logged out (currentUser = Nothing)? > > Am I thinking about this in the wrong way? > > > > On Wednesday, July 6, 2016 at 3:12:54 PM UTC-4, Scott Corgan wrote: >> >> Here's an article that elaborates a bit more: >> https://www.brianthicks.com/post/2016/07/05/duplicate-message-or-update-contexts-in-elm-components/ >> . >> >> Then, in each parent's update function, you are calling the child's >> update function. But, instead of just calling "ChildComponent.update msg >> model", you'll call "ChildComponent.update context msg model" >> >> Does that help? >> >> >> On Wed, Jul 6, 2016 at 2:57 PM Erik Lott <[email protected]> wrote: >> >>> Can you explain how this works? >>> >>> >>> >>> >>> On Wednesday, July 6, 2016 at 2:37:57 PM UTC-4, Scott Corgan wrote: >>>> >>>> It seems like the easiest approach at this point is a combination of >>>> binding a context type as the first argument to your update functions and >>>> sending the Navigation.newUrl command from the updateUrl function (used by >>>> Navigation). >>>> >>>> urlUpdate : Context -> Navigation.Location -> ( Model, Cmd a ) >>>> >>>> and the rest of the update functions: >>>> >>>> update : Context -> a -> Model -> ( Model, Cmd a ) >>>> >>>> On Wednesday, July 6, 2016 at 2:05:25 PM UTC-4, Erik Lott wrote: >>>>> >>>>> *Is there an idiomatic/proven way to approach Authentication in an Elm >>>>> single page app?* Sadly, there are very few resources online that >>>>> touch on authentication, yet it's an unavoidable part of SPA development. >>>>> It would be great if this discussion could serve as the best answer to >>>>> this >>>>> question. >>>>> >>>>> In our case, I am evaluating Elm for a Single Page Application. We >>>>> have a simple json api, as follows: >>>>> >>>>> The API: >>>>> >>>>> >>>>> - POST /sessions - post a username/password. If the credentials >>>>> are authentic, it returns 200 OK along with a secure http-only cookie. >>>>> - GET /me - returns 200 OK with user record or 401 Unauthorized >>>>> >>>>> >>>>> Our Elm requirements: >>>>> >>>>> - When the client app loads, it makes a request to /me to see if >>>>> the user is currently logged in. If 200 OK, store the current user in >>>>> elm >>>>> and display to the Dashboard page. If not, display the login page. >>>>> - On a successful login, make a request to /me to retrieve the >>>>> current user record, store the current user in elm, and display >>>>> the Dashboard page. >>>>> - If an API response ever returns 401 Unauthorized, remove the >>>>> current user record on the elm model, and display the login page >>>>> >>>>> >>>>> I'm sure that any guidance from community would be appreciated by all! >>>>> >>>>> >>>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Elm Discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
