Shared AuthManager
Dmitry Dzhus
well as some other nested `Snaplet ChildHelper`. How am I supposed to
to get access to AuthManager from ChildHelper? This seems similar to
using Heist singleton nested in top-level snaplet along with HasHeist
typeclass (and just like with Heist, single AuthManager per whole
application seems like a common pattern), but there's no such class
provided by Snap for AuthManager (like HasAuth). Declaring it in my
top-level App code would lead to circular dependency between App and
ChildHelper (also I maintain them as separate projects). Wouldn't it
be wise to add HasAuth to Snap.Snaplet.Auth?
MightyByte
authentication for a site. That's why we didn't include HasAuth.
It's certainly true that most simple apps probably won't need more
than one instance, so I guess our decision here is debatable.
However, the way of accessing AuthManager from ChildHelper is to pass
the AuthManager lens into ChildHelper. Then from within ChildHelper
you can use that lens and the withTop function to do things with the
auth snaplet.
Dmitry Dzhus
> We can envision situations where one might want multiple methods of
> authentication for a site. That's why we didn't include HasAuth.
> It's certainly true that most simple apps probably won't need more
> than one instance, so I guess our decision here is debatable.
anyways,
and will be quite useful for majority of cases.
> However, the way of accessing AuthManager from ChildHelper is to pass
> the AuthManager lens into ChildHelper. Then from within ChildHelper
> you can use that lens and the withTop function to do things with the
> auth snaplet.
MightyByte
> On 21 фев, 09:56, MightyByte <mightyb...@gmail.com> wrote:
>> We can envision situations where one might want multiple methods of
>> authentication for a site. That's why we didn't include HasAuth.
>> It's certainly true that most simple apps probably won't need more
>> than one instance, so I guess our decision here is debatable.
>
> Adding HasAuth will not limit developers to use single manager
> anyways,
> and will be quite useful for majority of cases.
There are two levels of HasAuth convenience. The first level is just
the existence of the HasAuth type class. You can easily bolt this on
in your own code with no changes at all to the snap project. This
allows you to avoid passing the lens around everywhere, but still
requires you to use "with authLens" everywhere (where authLens is
defined by HasAuth).
The second level of convenience is where all the existing functions in
the auth API are modified to use authLens. In general this would
result in type signatures changing from
Handler b (AuthManager b) a
to
HasAuth b => Handler b v a
This change is what I was referring to and does limit developers to a
single instance of the auth snaplet.