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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
