Guidelines for using shiny new client session library?

[Norman Ramsey]

I'm an experienced Haskeller but have never written a web app before.

I've made substantial progress starting with the Happstack Lite sample

application (which is really grade) and have added a lot of acid-state

functionality. 

I've reached the stage where I'm ready to try to "log in" to my application

as a particular user.  I've spotted Happstack.Server.ClientSession, which

does indeed look very shiny.   I have two questions:

  - Does anyone have a simple example client?  Perhaps which could

    be added to the crash course?

  - Where should I go to be informed about sessions more generally?

To provide a little more depth, here is some information about my app:

All I want to do with a session is relieve my users of the need to 

authenticate themselves repeatedly.  After authentication I want

to store a suitably encrypted cookie (secure, HTTPOnly) which

will identify the user and allow me to display only the information

to which the user has the rights.  I have no interest in supporting

any external authentication scheme.  

Norman Ramsey

[dag.od...@gmail.com]

Have you seen the demo application?

http://patch-tag.com/r/mae/happstack/snapshot/current/content/pretty/happstack-clientsession/demo/demo.hs

 It should be fairly straight-forward to adapt it to something that stores some UserID newtype that is looked up in acid-state.

Hope that helps!

Dag

[Jeremy Shaw]

Hello,

Are you looking for something more in-depth than the example and
documentation provided here:

http://www.happstack.com/docs/happstack-clientsession-7.1.0/doc/html/happstack-clientsession/Happstack-Server-ClientSession.html

It doesn't sound like you actually intend to store anything in the
client session. Perhaps you just want to use https and a plain-old
cookie with the secure and httpOnly flags set?

You can use System.Entropy to generate a suitable random token,

http://hackage.haskell.org/packages/archive/entropy/0.2.1/doc/html/System-Entropy.html

clientsession is typically used when you want to store some data
associated with a visitor, but you don't want to have to store it in a
server-side database. Note that the data will be associated with the
browser, not the user account. So, if they login on another machine..
that information will not automatically be available. Since you
already have accounts -- it seems like you would want to store
'session' information on the server?

- jeremy

> --
> You received this message because you are subscribed to the Google Groups
> "HAppS" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/happs/-/nctt_lHNwLsJ.
> To post to this group, send email to ha...@googlegroups.com.
> To unsubscribe from this group, send email to
> happs+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/happs?hl=en.

[Norman Ramsey]

Thanks Dag and Jeremy!

I simply want to store my user's (encrypted) identity so that once a user is 

authenticated, the authentication does not have to be repeated as long as

the browser window stays open.  It sounds like HTTPS and a simple secure,

httponly cookie might be a better plan, because then if I wanted I could allow

the cookie to live longer than just a session---I would see what the users say.

I did look at the example client, and I found the code very straightforward,

but the types made my head explode.  I am still using Happstack.Lite with

just a tiny addition to provide access to 'guessContentType'.  The combination

of monad transformers is something I will have to go off and study.

(But eventually I hope to figure out how to use a reader/environment monad so that

I  don't have to pass my acid-state everywhere explicitly.)

I am really enjoying using both Happstack and acid-state, although as my app

takes shape I am too forcibly reminded that as a web designer, I am rubbish.

Thanks again for these great tools!

Norman

[dag.od...@gmail.com]

On Thu, May 24, 2012 at 9:00 PM, Norman Ramsey <fells...@gmail.com> wrote:

Thanks Dag and Jeremy!

I simply want to store my user's (encrypted) identity so that once a user is 

authenticated, the authentication does not have to be repeated as long as

the browser window stays open.  It sounds like HTTPS and a simple secure,

httponly cookie might be a better plan

"Secure" cookie is a bit misleading - a user can change its value if you're not using something like clientsession. So for this plan to work you would need to put some random, unique and unguessable token in the cookie. I'm not sure if this is less work than using clientsession, though.

 

, because then if I wanted I could allow

the cookie to live longer than just a session---I would see what the users say.

The clientsession cookie is in the end just a normal cookie and you can set its lifetime in the SessionConf, so that shouldn't be a problem.

 

I did look at the example client, and I found the code very straightforward,

but the types made my head explode.  I am still using Happstack.Lite with

just a tiny addition to provide access to 'guessContentType'.  The combination

of monad transformers is something I will have to go off and study.

(But eventually I hope to figure out how to use a reader/environment monad so that

I  don't have to pass my acid-state everywhere explicitly.)

This is documented in the Crash Course:

http://www.happstack.com/docs/crashcourse/AcidState.html#acid-state-advanced 

I am really enjoying using both Happstack and acid-state, although as my app

takes shape I am too forcibly reminded that as a web designer, I am rubbish.

Perhaps try something like the Twitter Bootstrap:

http://twitter.github.com/bootstrap/

Then using that as a base you can customize with colorso that you can find here:

http://www.colourlovers.com/

I find tools like that make it easier to make beautiful designs without being a great designer yourself.

[Jeremy Shaw]

Great! Feel free to ask questions if you get stuck. Everything makes
perfect sense to *me*, so getting user feedback is crucial for
figuring out what needs better documentation.

The types for clientsession are a bit intense. We are moving towards
building another layer on top of happstack, but we are not quite there
yet.

the ServerPart monad is lightweight -- and easy to use, but does not
do much. Then we have optional packages like clientsession which can
be combined together to add more power. But keeping things flexible
means more complex types.

The next thing to do is to build a 'fat' monad on top of of the
low-level pieces that ties everything together and gives you back a
nice simple type signature again. For example, we might have a
'happstack-heavy' package, which contains simple type signatures the
way 'happstack-lite' does. But 'happstack-heavy' would include things
like sessions out of the box. The tradeoff is that you get less
flexibility. But, the payoff is that someone already picked the 'best
choices' for you, and wrapped everything up into a simple package.

I think that is pretty valuable -- because having your choice of
solutions is useless if you are not qualified to evaluate what you
need. Better to have someone pick a bunch of reasonable defaults for
you. Later, you can change components if you realize that something
else really would work better in your case.

Regarding acid-state and ReaderT, you should check out this section of
the crash course when you are ready:

http://www.happstack.com/docs/crashcourse/AcidState.html#acid-state-advanced

That section actually solves the problem of being able to access
multiple acid-state handles transparently, but it works just as well
for a single acid-state handle.

You will notice in that section that I combine the ServerPartT and
ReaderT monads. But to keep my type signatures from going insane, I
wrap them inside a newtype, 'App' which automatically derives all the
same instances as ServerPart. In addition to keeping the types simple,
that alsomeans that we don't have to use 'lift' or anything fancy to
call normal Happstack functions.

I find that newtypes make using monad transformers pretty painless and
transparent. The only horrid part is the one line of code where you
have to unwrap the newtype and flatten all the monad transformers.
But, fortunately, you only have to write that once-per-app.

The unwritten Part II of the crash course will cover a bunch of 'best
practices' topics like this. Part I discusses how to use the parts in
isolation -- but combining them in a sensible manner is a whole other
skill.

- jeremy

> --
> You received this message because you are subscribed to the Google Groups
> "HAppS" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/happs/-/1j-8CjRpyUcJ.