Evaluating mongo-auth logged in status within the same request (AJAX auth)

[Gustav van der Merwe]

So, I think I have come across an issue, I just want to run the behaviour through the list before I open an issue, both how I discovered it and what I think it is exactly.

The issue basically is that evaluating:

<span id="user-email" data-lift="Menu.item?name=user-page">{ user.email.value } - </span>

hides the menu item when delivered via AJAX immediately after login where the Menu item in question is guarded by RequireLoggedIn. The user is however successfully logged in and on subsequent requests the exact same template above renders fine.

RequireLoggedIn is defined like so:

val RequireLoggedIn = If(
() => userMeta.isLoggedIn,
() => RedirectToLoginWithReferrer)

where def isLoggedIn: Boolean = currentUserId.isDefined

The two variables holding the current user information are:

private object curUserId extends SessionVar[Box[String]](Empty)
private object curUser extends RequestVar[Box[UserType]](currentUserId.flatMap(findByStringId))

Now, upon successful login I rerender some parts of the page to indicate the user is logged in and to give them some new links. This is guarded by a match on User.currentUser which in the end refers down to curUser via:

def currentUser: Box[UserType] = curUser.get

whereas RequireLoggedIn which guards the rendering of the Menu items in question refers down to curUserId with below as the bridge:

def currentUserId: Box[String] = curUserId.get

So, there is in the exact same codepath two conflicting pieces of information around whether or not the user is logged in.

Thoughts on this?

Regards,
Gustav van der Merwe

[Tim Nelson]

Hi Gustave,

I'm not quite sure I understand what's going on. I think this would be a lot easier for me to help with if you could create a small demo app that reproduces what you're seeing.

Tim

[Gustav van der Merwe]

Hi Tim and all.

I've setup something at https://github.com/gvdm/ajax-login-mongoauth-render - by doing so I've slightly broadened the scope, seems the issue is with evaluating Menu.item within a NodeSeq being passed via SetHtml.

Let me know how I can help describe the issue further, the code does demonstrate the issue though, the login button should return some html to be set, and doesn't. Not too sure about the exact cause now though as pressing the button later again does still not return a rendered menu.

Regards,
Gustav van der Merwe

> --
> --
> Lift, the simply functional web framework: http://liftweb.net
> Code: http://github.com/lift
> Discussion: http://groups.google.com/group/liftweb
> Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
>
> ---
> You received this message because you are subscribed to the Google Groups "Lift" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com <mailto:liftweb+u...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

[Antonio Salazar Cardozo]

I haven't gotten a chance to look at the repo/code, but keep in mind that the lifetime of

a RequestVar is the initial request + any related AJAX requests! “Related” here means

“done via Lift mechanisms”, i.e. bound functions. If you want it to mean “the current actual

HTTP request”, use a TransientRequestVar instead.

Thanks,

Antonio

> To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com <mailto:liftweb+unsubscribe@googlegroups.com>.

[Gustav van der Merwe]

On 04/06/15 17:33, Antonio Salazar Cardozo wrote:
> I haven't gotten a chance to look at the repo/code, but keep in mind that the lifetime of

> a RequestVar is the initial request + /any related AJAX requests/! “Related” here means

> “done via Lift mechanisms”, i.e. bound functions. If you want it to mean “the current actual
> HTTP request”, use a TransientRequestVar instead.

Well, when you do get a chance to look at the code you'll see I make use of no *Vars to reproduce this issue, the reference to *Vars was to MongoAuths internals.

[Tim Nelson]

Hi Gustave,

Thanks for making the demo app. It made it easy to track down.

The problem isn't with the session/request variables, it's with the Menu snippet. If you look at line 443 [1], it matches on a 3 item tuple. The first 2 items return Empty. S.param is obviously Empty because we're not using it. The problem lies in `S.request.flatMap(_.location)`. Why that's Empty, I'm not sure. S.request itself is Full.

Maybe Antonio can shed some light on why location is Empty during an ajax call.

Tim

1 - https://github.com/lift/framework/blob/master/web/webkit/src/main/scala/net/liftweb/builtin/snippet/Menu.scala#L443

[Tim Nelson]

Btw, here's the code I used to track down the problem: 

https://github.com/eltimn/ajax-login-mongoauth-render/commit/3c7e3cc1212c9fd2b9ea0b6af21ed00e8a6ea032

[Antonio Salazar Cardozo]

I believe `location` is the Loc associated with the current HTTP request. For AJAX requests,

there is no such Loc. S.originalRequest.map(_.location) would probably be the better move in

that case, and that may be the most reasonable thing to do in Menu… Not sure.

It definitely feels like there should be an extra case in that statement, case (_, _, Full(loc))…

It just blows my mind that this wouldn't have been noticed before now, and makes me suspicious

that I'm missing something heh. The implication is that Menu.item has never been able to

render a link for a page that wasn't *either* the current one *or* had a parameter, if I'm not

reading the code wrong.

Thanks,

Antonio

[Tim Nelson]

That was confusing me as well for awhile, but, in some of those cases the link is built with the buildLink function, which uses the name that was passed in. But, it does need the current Loc to build it with.

I think you're right, though, that S.originalRequest.flatMap(_.location) would probably be better in  the snippet. I updated my fork and it does indeed fix the problem.

[Gustav van der Merwe]

Should I open a ticket for this or will someone get around to committing this one liner for M6?

Regards,
Gustav van der Merwe

On 04/06/15 20:24, Tim Nelson wrote:
> That was confusing me as well for awhile, but, in some of those cases
> the link is built with the buildLink function, which uses the name
> that was passed in. But, it does need the current Loc to build it
> with.
>
> I think you're right, though, that
> S.originalRequest.flatMap(_.location) would probably be better in
> the snippet. I updated my fork and it does indeed fix the problem.
>
> On Monday, April 6, 2015 at 12:48:46 PM UTC-5, Antonio Salazar
> Cardozo wrote:
>
> I believe `location` is the Loc associated with the current HTTP
> request. For AJAX requests, there is no such Loc.
> S.originalRequest.map(_.location) would probably be the better move
> in that case, and that may be the most reasonable thing to do in
> Menu… Not sure.
>

> It definitely /feels /like there should be an extra case in that

[Tim Nelson]

Please open a ticket.

[Gustav van der Merwe]

On 04/09/15 13:22, Tim Nelson wrote:
> Please open a ticket.

I have opened the issue here https://github.com/lift/framework/issues/1695 - can anyone spare a moment for this? It seems to literally be a one line fix that needs to be committed.

[Tim Nelson]

Hi Gustav,

I'll try to get that done today.

Tim

[Antonio Salazar Cardozo]

On Friday, May 22, 2015 at 3:55:11 AM UTC-4, Gustav van der Merwe wrote:

On 04/09/15 13:22, Tim Nelson wrote:
> Please open a ticket.

I have opened the issue here https://github.com/lift/framework/issues/1695 - can anyone spare a moment for this? It seems to literally be a one line fix that needs to be committed.

Literally a one-line fix in a core part of the framework that is quite complex. One line

is not always trivial ;)

Thanks,

Antonio

[Tim Nelson]

On second thought ...

Although that is a pretty small change, it does have a significant impact as I'm sure that's being used by a lot of projects.

Since I'm not that familiar with Lift's internals I wouldn't feel comfortable making this change without a lot of rigorous testing. Besides it's a real easy workaround to just copy that function into your own snippet and make the change there.

Tim

[Tim Nelson]

Hi Gustav,

A fix for this was just merged with master. Please give it a try.

Tim