IP address range locking
hi, i am implementing IP address range locking for my application as i have a number of offices that need to access the application and everyone else needs to be kept out. i am using WicketAuthRoles and have placed the code into my login page... before attempting authentication i match the client's IP against a number of defined ranges that i deem safe so can throw incorrect connections out with an error(message here) and it will redisplay the login page with the message in the FeedbackPanel. i am thinking however that this is not really correct... really the IP range locking should be more of a system thing rather than a component thing. i want my users to be able to stay logged in so have a cookie holding auth info but this means they will bypass the login screen if they take their laptops to a different network which is not good. it sounds like i need to put the code into the Session or something but that would mean i could never throw a message back to the user to say what the problem is as the error page would have to come from me. i guess i could have a single JSP page holding the error message and throw the user out of the Wicket application into this page but i'd prefer to keep everything inside my Wicket application if at all possible... does anyone have any ideas on how best to handle this? John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IP address range locking
you should do this on httpd server level or even firewall level. In our app we restrict access to specific private pages to just our corporate IP using mod_jk with locationMatch ... rules. Martijn On Fri, Oct 17, 2008 at 1:25 PM, John [EMAIL PROTECTED] wrote: hi, i am implementing IP address range locking for my application as i have a number of offices that need to access the application and everyone else needs to be kept out. i am using WicketAuthRoles and have placed the code into my login page... before attempting authentication i match the client's IP against a number of defined ranges that i deem safe so can throw incorrect connections out with an error(message here) and it will redisplay the login page with the message in the FeedbackPanel. i am thinking however that this is not really correct... really the IP range locking should be more of a system thing rather than a component thing. i want my users to be able to stay logged in so have a cookie holding auth info but this means they will bypass the login screen if they take their laptops to a different network which is not good. it sounds like i need to put the code into the Session or something but that would mean i could never throw a message back to the user to say what the problem is as the error page would have to come from me. i guess i could have a single JSP page holding the error message and throw the user out of the Wicket application into this page but i'd prefer to keep everything inside my Wicket application if at all possible... does anyone have any ideas on how best to handle this? John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IP address range locking
hi, yes that makes a lot of sense. unfortunately i have to implement it in the application in this instance. i need to alter the ranges at runtime with as little complexity as possible... anything that acts outside the application makes everything more complicated than i can handle right now... also it would be nice to be able to set different IP ranges for different users in the end so i can allow certain people to log in from their home network. because of this, i guess this must be in the auth stage somewhere. maybe the login page is the best place for it primarily but i need to find some way to intercept the cookie check as well? what do you think? John On Fri, Oct 17, 2008 at 12:56 PM, Martijn Dashorst [EMAIL PROTECTED] wrote: you should do this on httpd server level or even firewall level. In our app we restrict access to specific private pages to just our corporate IP using mod_jk with locationMatch ... rules. Martijn On Fri, Oct 17, 2008 at 1:25 PM, John [EMAIL PROTECTED] wrote: hi, i am implementing IP address range locking for my application as i have a number of offices that need to access the application and everyone else needs to be kept out. i am using WicketAuthRoles and have placed the code into my login page... before attempting authentication i match the client's IP against a number of defined ranges that i deem safe so can throw incorrect connections out with an error(message here) and it will redisplay the login page with the message in the FeedbackPanel. i am thinking however that this is not really correct... really the IP range locking should be more of a system thing rather than a component thing. i want my users to be able to stay logged in so have a cookie holding auth info but this means they will bypass the login screen if they take their laptops to a different network which is not good. it sounds like i need to put the code into the Session or something but that would mean i could never throw a message back to the user to say what the problem is as the error page would have to come from me. i guess i could have a single JSP page holding the error message and throw the user out of the Wicket application into this page but i'd prefer to keep everything inside my Wicket application if at all possible... does anyone have any ideas on how best to handle this? John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
