On Friday, September 16, 2016 at 1:32:06 AM UTC+1, art yerkes wrote:
>
> HttpError has BadResponse Int String which you can use to detect non-200
> results to http requests. The way to do it in elm is to write a function
> that wraps the creation of login enabled http requests and translates 401
> errors into a suitable message (which is why Task.perform has two function
> arguments: one for errors, one for successes). As long as your code uses
> the wrapper, you'll consistently translate errors into useful messages.
>
Very useful, thanks. I was thinking I would have to write the 401 handling
code on every request - but with a wrapper function that can be done just
once and put in place with the wrapper.
I still have to put the wrapper on all requests that need it, rather than
just once in a global interceptor, but that actually sounds like a better
approach to me.
>
> You can use elm-navigation to "save your place" to a degree when
> redirecting to a separate page and back by storing some state in the url's
> fragment. (I haven't tried it, but newUrl in this library seems like it'd
> support redirection too). You can of course get much fancier.
>
Yes, I kind of discovered this by accident. When not logged in, I show the
login page, but did not change the url - so once login completes the
original page comes back again.
> If your login page can send a message to a parent frame, you can use
> Dom.LowLevel.onWindow to receive it in elm. This appeared in 0.17 and is
> neat.
>
> In my elm code, I separated out the login http handler with its own Model,
> init and update functions and delegated handling of login related messages
> to it via elm architecture style message wrapping, but you don't need to
> get that fancy unless it makes your code more readable to do so.
>
This is also what I am trying to do. Interaction with the 'auth' module is
needed from many places in the application - the login page (login), the
top-level view (isloggedIn), the logout button wherever that lives
(logout), everywhere that makes http requests (on 401 - setLoggedOut). It
would be nice to capture all these actions in a module in such a way that
invoking them from anywhere within the application is easy to do.
If I was doing this in Java, I would write an interface, and pass its
implementation around wherever it is needed:
public interface AuthHandler {
boolean isLoggedIn();
void login(String username, String password);
void logout();
void setLoggedOut();
}
Is your code somewhere I can look see?
> On Thursday, September 15, 2016 at 9:27:52 AM UTC-7, Rupert Smith wrote:
>>
>> My next project is delving much deeper into Elm - until till now I mostly
>> just played around with the view and a little bit of glue to stick it all
>> together.
>>
>> The code I am porting to Elm is an Angular project that has a fairly
>> sophisticated way of handling logins. When a resource is accessed on the
>> server and the user is not logged in, a 401 Unauthorized is sent back.
>> There was a way in Angular to intercept this, pop-up the log in dialog, and
>> upon succesful completion of the log in, the request that failed is
>> replayed. I was getting a bit fancy with that, and don't necessarily need
>> to do it exactly that way in Elm. What would do for now is 401 -> redirect
>> to login page -> come back to some starting page for the application.
>>
>> Is there some way in Elm to set up a global HTTP interceptor to look out
>> for 401s?
>>
>
--
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.
