Forum Discussion
Brian_69413
Nimbostratus
NimbostratusSSL vs Non-SSL portions of the a website
How do you folks handle SSL(protected) vs non-SSL(public) content on a website while holding persistence for authed users.
We have a site where visitors can log in to view customized content or browse as a guest and see default content.
When they get to protected pages, they need to be logged in and the site needs to switch to SSL, but the rest of the site we would like to be non-SSL.
If we have two virtuals, one for port 80 and the other for port 443, but a shared pool of servers, how would we handle keeping a user with a particular server(persistence) to keep them logged in?
Lots of e-commerce sites do this, and I hope it does not have to be by replicating session data between servers...
HamishCirrocumulus
You can do persistence across virtual servers with a persistence profile... There's 3 options, selectable individually to match across services, virtual servers and pools. You really just want to match across virtual servers (i.e. your port 80 and your port 443 VS). The persistence profile can be of any type (So it'd probably be cookie in your case).
That should do what you want...
H
Brian_69413That is certainly easier than I expected...so a session cookie, for example, will hold true to a pool member even when swapping virtuals with the same pool? What would that session cookie do for you if it was a different pool with different members in the second virtual?- HamishWhat the session cookie does for you depends on whether it's set for persistence within a VS only, across a service, across VS's, or across pools...
A normal session cookie (NO matching) will be ignored by a second VS with a different pool.
A persistence across services will ensure that the same pool behind two VS's with the same IP wil hold persistence for a client (i.e. client will hit the same poolmember for :80 and:443 on site.com).
A persistence across VS's will ensure that my1.site.com:80 and my2site.com:443 will hold persistence for a client.
A persistence across pools will ensure that even if the pools are different...Note that the membership of the default pool in this instance isn't checked... So it could lead to a security hole in your site if you don't encrypt the cookie...
H - HamishThe (vulnerability?|Opportunity for a more interesting life?) exists in match across pools... I don't believe it exists in match across VS and service (But haven't checked), but it's certainly worthwhile making sure that if you have persistence across anything and are using cookies, then make sure you encrypt the cookie...
H - Brian_69413Persistence across service is all I would need. Thanks for this insight!
- One thing to note. If you're looking to maintain persistence using the same exact pool across multiple VSs, you can maintain persistence via inserting a custom cookie (specify the name), no need for "match across" option..
Since the pool members are the same and if specify the cookie name the cookie will be the set the same when you hit the different VSs with the same exact pool.. This will work even when hitting a completely different LTM, considering the Pool makeup is exactly the same..
That specific scenario isn't documented well anywhere.. but I can confirm it works as I'm using it in multiple high volume production environments..
sol6917: Overview of BIG-IP persistence cookie encoding
http://support.f5.com/kb/en-us/solutions/public/6000/900/sol6917.html?sr=13525090
sol5837: Match Across options for session persistence
http://support.f5.com/kb/en-us/solutions/public/5000/800/sol5837.html?sr=16887030
