suppressing session cookies (and sessions) for anonymous users

[eluser]jayjanssen[/eluser]
Hi, I'm looking to scale a CI site (I'm not the developer) and I'm working on trying to cache a lot of the general pages.

I think with my webserver I can essentially set it up to serve cached pages to users that don't have a certain cookie, and serve dynamic php pages to those who do have the cookie. (I emphasize "think")...

My only problem is that CI seems to set the session cookie immediately, even for anonymous users.

Is there any way to disable session tracking for anonymous users? (not storing sessions would be valuable for performance reasons with our without caching). Thanks!

[eluser]yoda.pt[/eluser]
Hi,

Yor question is confusing. How do you choose who will have the cookies set? And by the way, is there another background objective for that requirement?


Cheers

[eluser]jayjanssen[/eluser]
>How do you choose who will have the cookies set?

Well, if I had a choice, I'd only give a cookie (and a session) to a logged in user.

> is there another background objective for that requirement?

The objective is performance during a heavy traffic spike. If the site ends up on digg or wherever, the majority of users will come to see it, but not bother to register or log in. If I can at least cache pages for anonymous viewers, I can go a long way to surviving the traffic spike without my server croaking.

If anonymous users didn't have a certain cookie, I could use that as a way to determine whether or not I should serve a cached page or not (i.e., are they anonymous or a real user).

Keeping sessions off of anonymous users would be very useful for that, since having a session = reading and writing to the db (assuming a db session).

[eluser]yoda.pt[/eluser]
Hi,

First, what Session library are you using?

Second, I think what you want isn't nothing special really. Based on the fact that every user, logged or not, has access to page xyz.php (example), the only thing you have to do is check on the controller if the user is logged in, and find a way to call the cached page.

Know, about cached pages, is something I've never used really. But I might just do a little search about it!

EDIT: you may wanna look at this topic: Cache library

[eluser]Mirage[/eluser]
Yoda -

Perhaps you just need to rethink your approach a little. There's more than one way to solve this problem.

First of all - COOKIE does not equal SESSION. In other words you can set plenty of cookies in the browser without hooking them to the server side session. It appears to me that you are autoloading the session - which is what creates the cookie automagically and thus your dilemma.

As the previous poster asked, it's relevant which Session Library you use. CI's native Session Library only uses a Cookie anyway, which makes it extremely scaleable [although limited in storage]. If you are using a server side session (file or database), then we're talking a little something different. Let's go forward assuming that you are using server side storage for your session, which you'd like to avoid invoking when guests visit the public site.

If your site/application is truly this separated you should perhaps cache all output and only avoid this when protected pages are visited. This should be easy enough to distinguish in your controllers. So in your protected areas you load the session in the controller constructor or a post-constructor hook. Further you can override the CI cache for all your protected pages using a hook.

A question I have is - why would you want to differentiate whether or a logged in member or guest is browsing your 'public' page. Shouldn't those be cacheable for all visitors?

[eluser]jayjanssen[/eluser]
> why would you want to differentiate whether or a logged in member or guest is browsing your ‘public’ page. Shouldn’t those be cacheable for all visitors?

They are cacheable, with the following exceptions:
- The little "<username> | Log off" button at the top of the page
- Some pages with user-specific data

The first one is the main problem, I don't want to present a 'Log in' link to a logged in user, etc. One possible solution we came up with was to make that little block be an ajax call that amounts to it being its own separate little page. That, of course, adds more hits to the webserver, and still means a php hit for every anonymous user, but it's better than nothing.

[eluser]Mirage[/eluser]
Ok, so this makes some sense.

I don't think you'd need to use AJAX to update the element. You could just use Javascript to examine a given cookie for presence or content to change the content of that page element.

Pages that mix user-specific data of other kinds are of course animals of a different color. I think that AJAX updating could possibly apply here. Otherwise I think you'll have to augment CI's caching mech by either using a custom library OR extending CI's library to support caching of fragments rather than they whole page. Alternatively you could work out a solution where the cache library would accept additional qualifiers. This would essentially allow you to cache pages on a per-session basis.

Cheers
-m

[eluser]jayjanssen[/eluser]
[quote author="CI Mirage" date="1217535619"]Ok, so this makes some sense.
I don't think you'd need to use AJAX to update the element. You could just use Javascript to examine a given cookie for presence or content to change the content of that page element.
[/quote]

Isn't that what AJAX is?

[eluser]Mirage[/eluser]
[quote author="jayjanssen" date="1217536185"]Isn't that what AJAX is? [/quote]

Not to me. AJAX (Asynchronous JavaScript and XML) requires Javascript and XMLHttpRequest as far I interpret the terminology. You don't need AJAX to check a cookie, just JavaScript. :-)