What's the best method for creating a members only area (whilst using SQUID)

(Kequi) #1

I’ve struggled with this for some time - so wondered what other people think.

Simplest option is to remove SQUID and stop caching once users login. So Matrix runs all conditional usergroup bits and pieces and logged in users always see the correct content.
However that’s not really an option for us - without SQUID some data heavy pages can take a very long time to load.

In addition - all logged in users see the same content anyway (it’s not personalised to individuals) - so I think it makes sense to utilise SQUID if possible.

The options seem to be:

  1. Use a subdomain EG: members.mysite.com
    Have users redirected once logged in - and have all the conditional stuff based on whether the domain is “members.”
    SQUID caches the members. url differently to www.

  2. Use folder structure EG: www.mysite.com/members/
    Use contexts to have users redirected on login and to show alternative content
    SQUID caches the urls differently

  3. Use a query string EG: www.mysite.com?member=yes
    Have users redirected once logged in - and have all the conditional stuff based on whether the query string contains “members=yes”
    SQUID caches the url with the query string as a unique url

Obviously there’s a bunch of other stuff to think about:

  • Redirecting logged in / not logged in users
  • Do members need to view ALL pages using the new urls - or just the pages with additional members content (there’s more chance of the public pages being cached)

What do you think is the preferred option with Matrix? (I’m leaning towards version 2)

What are the important other factors that should be considered?

Thoughts / advice / experience gratefully received as always

Karl

(Marcus Fong) #2

As you’re probably finding out, this can be a bit tough in Squid.

I definitely would not try your option 3, because once something gets cached in Squid it’ll happily serve that content to anyone who asks. So you run a real risk of your logged-in content being exposed to all and sundry, if they stumble on the right URL.

The first two should be doable - by default Matrix doesn’t send cacheable headers for logged-in users. So Squid wouldn’t cache anything for the logged-in users, and as long as there’s no URL overlap between the two classes of users you ought to be fine. Obviously, though, you lose all the benefits of Squid for logged-in users by doing this.

Depending on the nature of your site it’s sometimes also feasible to cache the bulk of a page in Squid and use AJAX to pull in just the parts which require login. This requires careful thought and planning, however, and can be very difficult to retrofit to a site that wasn’t designed for it in the first place.

If optimal performance for your logged-in users is of critical importance, then there are also potentially other, non-Squid alternatives that could be explored depending on your particular requirements - but detailed project-specific discussions are getting a bit beyond the scope of this forum. If that might be of interest to you then contact your Squiz account manager.

(Kequi) #3

Thanks Marcus - your feedback is much appreciated,

The whole point would be to show SQUID cached pages to logged in users though - so I’ll need to switch on cacheable headers for logged-in users anyway (whatever method I use) right?

As for showing logged-in content to everyone if they know the url - can I not just add a trigger like “If public user loads a page with url containing /members/ - then redirect to url without /members/”

For the AJAX option do you mean the page would load from cache - but the AJAX would then load a non-cached element each time? So in effect the AJAX content is not cached as part of the url? So all of the conditional stuff (loggedin / not loggedin) would need to be part of the AJAX content.
So we would be in effect showing non-cached content each time?

Thanks

Karl

(Marcus Fong) #4

If you do this you’re basically making your logged-in pages public. You can’t get around this in the way that you’re thinking of - if you really do need this level of caching, then have a talk to your account manager about possible options. My experience has been that it requires a level of integration with Matrix that Squid can’t achieve.

No, you can’t. The reason is simple - a request served from Squid’s cache is not seen by Matrix, and thus doesn’t fire any Matrix triggers.

Yes. In many cases the majority of the time taken to generate a page is spent on the design and not the content itself, so even though the content is uncached there’s still a worthwhile performance benefit to be had (as compared to the whole page being uncached). Whether that’s true in your case would depend on the characteristics of your Matrix implementation.

Also note that even though the content may be uncached at the proxy level, it can still be cached in Matrix if it’s not specific to the individual user. This can be done by enabling Permission or Group level caching in the Matrix Cache Manager (in your case Permission level would probably be the most suitable, since you’ve indicated that all logged-in users should see the same thing).

(Kequi) #5

Thanks Marcus,

I’ve tested that option around using triggers to redirect if a user isn’t logged in - and it seems to work fine regardless of SQUID.

Surely triggers run even if the page is delivered via SQUID?

The only potential drawback I can see is if the trigger were to fail for some reason and a public user not be redirected - then the pages would be accessible.

(Marcus Fong) #6

If the trigger works then Squid didn’t serve the request from cache. Are cacheable headers enabled for non-public users?

(Note that if cacheable headers are enabled for non-public users then Squid will also cache the redirect, so depending on which user visited first you might also have a scenario where everyone will be redirected.)

Not if the page was served from Squid’s cache. For a trigger to run, the page has to be processed by Matrix - otherwise no PHP code executes. The entire point of Squid serving a request from cache is that Matrix doesn’t process the request. If this wasn’t the case then Squid would give no performance benefit at all.

(Kequi) #7

Thanks Marcus -

Many thanks for your info on SQUID - I wasn’t aware it bypassed the triggers also - so triggers like “asset accessed” etc simply won’t fire if the page is served from SQUID?

The SQUID system has no interaction with Matrix al all - and simply serves the raw html code it has previously stored?

Do you know how “contexts” system works with SQUID cache?

I’m assuming it’s similar - if a page is cached by squid then it will just cache the most recent context - and serve this html to the next person - ignoring subsequent contexts?
Do you have to switch SQUID off in order to make the contexts work - or use the alternative url structure (EG: mysite.com/context2/ - which I’m guessing would then result in a different SQUID cache)

Thanks again Marcus

Karl

(Marcus Fong) #8

Yes, that’s correct.

Matrix can and does interact with Squid via the Squid Clear Cache Tool, if that’s been configured. Squid, however, normally only interacts with Matrix when it comes to retrieving an uncached URL. When serving a cached object there’s no interaction.

Yes, in general the simplest method for contexts with Squid caching is to use URLs for your contexts.

If you’re already using a request header (like Accept-Language) for contexts, you could also configure your webserver to send a Vary header to Squid telling it to store different cache objects depending on that header… but the problem with Vary headers is that Squid’s PURGE method doesn’t support them very well, so you may have issues clearing your Squid cache if you do that.

#9

You can use Edge Side Includes (ESI) with SQUID: http://www.squid-cache.org/Doc/config/esi_parser/ & https://wiki.squid-cache.org/ProgrammingGuide/SquidComponents#ESI

(Marcus Fong) #10

In theory yes, but I understand from colleagues that our experiences with Squid and ESI have been very poor.

Perhaps the latest Squid 4 is better in this respect - we’ve only used the Squid versions packaged with Red Hat Enterprise Linux (2.6, 3.0 and 3.1).

#11

In what way it has been “poor”? ESI tags have nothing what so ever to do with Matrix or affect the way it generates content or behaves. In addition, Squiz EDGE (Squiz’s CDN solution) is using them without any issues.

(Marcus Fong) #12

If I recall correctly, the issue was with Squid’s own stability when processing ESI includes.

That’s completely true - there’s no problem with using Matrix and ESI. The problems I’ve heard of were specifically related to Squid and ESI.

Yes, we’ve used ESI with both Varnish and Squiz Edge with no issues. The issues I’ve heard of were specifically with Squid and ESI.

But as I said, it’s possible that the newer versions of Squid work fine now - as far as I’m aware we haven’t revisited the issue recently.

#13

Sorry, I read “Squid” as “Squiz” :smiley:

(Marcus Fong) #14

No problem, we make that typo a lot ourselves in e-mails and internal messages. :grinning: