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]
