Logged In Cookie 0.1

[RastaLulz]

RastaLulz submitted a new resource:

Logged In Cookie - Distinguish logged in users with a reliable cookie.

Overview:

As the title suggests, this add-on sets a cookie for logged in users.

This is particularly helpful if you want to implement caching for guests (through things like FastCGI cache, Varnish, etc.), as XenForo doesn't provide a reliable way to distinguish guests from logged in users out of the box (via cookies).

Features:

• Sets "(cookie_prefix)logged_in" (i.e. "xf_logged_in") cookie for logged in users.
• Displays page as a guest if user is logged in, and...

Read more about this resource...

 

[rdn]

After installing this addon, all my login users will automatically be logout? and need to login again?

 

[RastaLulz]

After installing this addon, all my login users will automatically be logout? and need to login again?

They won't be logged out per se, but they'll appear logged out on the first request, as the page will be rendered as a guest as they won't have "xf_logged_in" set. But on that first request the cookie will be set (assuming they're logged in), so they'll be logged in normally on the next request, whether they attempt to login, or click another link/reload.

 

[rdn]

Installed now on my Forum, and works as expected .

Thanks!

 

[eva2000]

very nice

 

[Nuno]

The next step would be a bypass to the thread and media counters so we could update our views.
With nginx/apache there is a way to archive this using SSI and an external file/mod to simulate varnish esi:

<!–# include virtual=“/viewscounter/thread/123”  –>

or

<!–# include virtual=“/viewscounter/media/123”  –>

At this time I only cache the front page, forums and members because of this ...
I'm not a knowledge xf developer so it's hard for me to do this!

 

[HWS]

The next step would be a bypass to the thread and media counters so we could update our views.

By default the view counters are also updated only every 15 minutes or so, they are not live. If you renew your cache every 5 or 10 minutes (which is very recommended) you do not need to exempt the view and media counters.

 

[Nuno]

But if the page is cached those views wont be counted since there is no phl/mysql work, only registered members will be counted.

 

[HWS]

But if the page is cached those views wont be counted since there is no phl/mysql work, only registered members will be counted.

Oh, I misunderstood you. Please disregard my former post.

 

[rdn]

Why is thread view really important with you guys?

 

[Mouth]

When you first install this, logged in users will see the first page they load as if they were a guest (since they don't have the logged in cookie yet), this is to prevent pages being cached with user information.

Any feedback on experience with this? Did users notice? Did it cause a stir? Did you advise first?

 

[RastaLulz]

Any feedback on experience with this? Did users notice? Did it cause a stir? Did you advise first?

From what I gathered, they just assumed they were logged out for whatever reason, and hit the login button at the top, and attempted to sign in normally. No one mentioned it, and when I asked, they simply stated they logged back in, and that was that.

 

[maxicep]

So, everyone advice that add-on for big boards ?
Did you see any incompatibility with other add-ons, especially redis caching ?

 

[rdn]

So, everyone advice that add-on for big boards ?

Not really, this addon is only needed if you use something like this:
https://xenforo.com/community/threa...fastcgi_cache-full-page-guest-caching.110806/

Did you see any incompatibility with other add-ons, especially redis caching ?

All fine for me.

 

[def]

So simple it should be built in option of XF! Thank you!

I try to use it with Varnish but for some reason logged_in cookie isnt dropped (all other cookies are, only session cookie stays).

So I am logged out, but the cookie is there, and guest page isnt cached.

Once I switch off varnish out of the loop and request goes directly to http server the cookie is deleted.

So it looks like this cookie isnt unset "at" logout, but "at" first request after logout. Is that correct? Any hint?

If thats correct, thats a pitty, because I would have to uncache "/" in order to allow cookie unset...

EDIT:
Weird, now I see other cookies are also not dropped and I cannot logout... I am playing with configuration, must have broken something...

 

[def]

@RoldanLT hmmm seems logout doesnt work at all... I cannot figure it out, why cookies are not dropped Have you had similar issue with NGinx caching? Varnish gurus out there?

 

[def]

Ok, got it.

vcl_backend_response had wrong order for POST method handling (simply it was after no-cache rules, but should be before). Learning every day

Works fine, testing.

Thanks @RoldanLT !

 

[rdn]

why cookies are not dropped Have you had similar issue with NGinx caching?

No problem on my Nginx fastcgi_cache setup .

 

[def]

May I request a feature?

Can the logged_in cookie contain a salted/keyed hash (HMAC) of user cookie instead of "1"?

Its easy to imagine DDOS attack with clients that have logged_in cookie set to 1, then every request goes straight to backend.

If instead of "1" it contains a hash of user cookie, I could validate the authenticity of the cookie (assuming key/salt is not known to the attacker) in the caching layer, without the need of passing it to the backend.

What do you think? I found Nginx mod that tries to implement similar approach - Lua Resty HMAC, maybe you could use it too in your scenario.

Idea:
http://info.varnish-software.com/blog/validating-cookies-varnish

Here is header example:
https://github.com/varnish/libvmod-digest

HMAC:
https://en.wikipedia.org/wiki/Hash-based_message_authentication_code