Forum Discussion
Andy_4937
Nimbostratus
NimbostratusAgreement Banner prior to site access
As a first time poster, please forgive my noobness.
I'm trying to establish an agreement banner before allowing access to the web server. I have a fully functioning VS with a complete iRule. I created an additional iRule and set a variable (Banner) upon RULE_INIT equal to the HTML code of my agreement banner. I then tried to use a session variable to check if the user has agreed to the banner or not. Once agreed, I would change the session variable to True and pass the user on to the functioning portion of my iRule. Basic code outline is this:
when HTTP_REQUEST {
session add uie Agree "False"
if {not ([session lookup uie Agree])}
{HTTP::respond 200 content $::Banner
session add uie Agree "True"
}else{
use pool webservers_pool
}
}
My result is, I see the agreement banner, but clicking Agree, which refreshes the page, continues to return me to the banner and never passes me past the if statement. My logic above is of course broken since I declare the var False just before I check it for True, however I can't seem to not declare the var, or to declare it in another event. Am I thinking wrong about how session variables work? Could there be a better way to handle this? I tried using a cookie as well, but with no success.
Any help is greatly appreciated!
4 Replies
- i bleieve this condition:
would always eval to True. Furthermore, it would always write to the same entry with a key of Agree.if {not ([session add uie Agree "True"])}
Something like this instead, maybe? (assumes clients all have unique source IPs, and you're using an idle timeout of 5 min):when HTTP_REQUEST { if {[session lookup uie [IP::client_addr]] equals "BannerSent"}{ forward to the pool pool webservers_pool } else { otherwise respond with the banner HTTP::respond 200 content $::Banner } in both cases, update the timer on the session session add uie [IP::client_addr] "BannerSent" 300 }
This will look to see if the client has already been sent the banner, if not will send it & set the session table entry, and update the timeout on the session table entry on every subsequent request.
Assuming the value of the content var includes some way to get back to the orignal request, that should work a bit better.
hth
/d - To explain the session table key issue a bit further: Furthermore, it would always write to the same entry with a key of "Agree", which means all clients after the first would find and/or overwrite the single existing session table entry. (session table entries are global, not automatically scoped to the conn like local variables are. You have to build that in by creating a key unique to each connection.)
Andy_4937Thanks for the info Deb, that helps clarify some things.
The IP address seems like a good idea, unfortunately most of my users are behind a single NAT, so that isn't an option.
I didn't realize session variables were global, I'll have to apply a unique variable per user if I stick with that method.
Can you clarify something with local variables for me? I'm reading that they are local to the connection. Does a connection remain open as long as the user is connected to that web session? Or is a connection simply the request / response per page request? Meaning, they access a page, a connection opens then closes and when they request another page, a new connection is established. Is that accurate?
Thanks!- Local vars are local to the connection (which may carry several requests if Keep-Alive). A session most often consists of multiple connections, and there is no way but the session table to share values between connections within the same session. So you're on the right path now if you can find a session ID to use as the session table key. It needs to be a value that that will be sent by the browser in every request, or in the first response and every subsequent request. One easy choice would be a session cookie the server is already setting.
/d
