Re: IoC question - introducing a time delay in an ASO
On Wed, Feb 11, 2009 at 8:25 AM, Peter Stavrinides p.stavrini...@albourne.com wrote: Hi everyone, Hi! What are the effects of using Thread.sleep(myInterval) in an ASO? My understanding is that each user receives a separate instance of the ASO, but not necessarily on a separate thread, right? Each user receives a seperate instance of the ASO. AFAIK, getting or setting an ASO does not spawn a new thread. Don't forget that every request is one thread, so it doesn't make much sense to use a new thread to deal with ASOs, as they're going to be used in the request processing. For me :), the biggest questions is why would you want to insert a delay in ASOs? If this is true then what happens after Thread.sleep is active, and the next user asks for his/her ASO? does a new thread spawn? or is there a lag? A lag. -- Thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: IoC question - introducing a time delay in an ASO
Hi Thiago, thanks for the reply, that is pretty much what I expected...
For me :), the biggest questions is why would you want to insert a
delay in ASOs?
I use an ASO as a token when signing users in, I use this small method to
introduce a time delay (if there are multiple failed attempts, I increase the
delay):
private void incrementFailedLoginCount() throws InterruptedException {
failedLoginCount_ += 1;
if(failedLoginCount_ == 5){
sleepCount +=1; failedLoginCount_ = 0;
Thread.sleep(SLEEP_INTERVAL);
SLEEP_INTERVAL = (SLEEP_INTERVAL * 2);
}
}
I haven't tested it much, but it seems to work great, I was just a bit worried
if it would be thread safe or if I was doing something stupid.
Cheers,
Peter
- Original Message -
From: Thiago H. de Paula Figueiredo thiag...@gmail.com
To: Tapestry users users@tapestry.apache.org
Sent: Wednesday, 11 February, 2009 13:04:17 GMT +02:00 Athens, Beirut,
Bucharest, Istanbul
Subject: Re: IoC question - introducing a time delay in an ASO
On Wed, Feb 11, 2009 at 8:25 AM, Peter Stavrinides
p.stavrini...@albourne.com wrote:
Hi everyone,
Hi!
What are the effects of using Thread.sleep(myInterval) in an ASO? My
understanding is that each user receives a separate instance of the ASO, but
not
necessarily on a separate thread, right?
Each user receives a seperate instance of the ASO. AFAIK, getting or
setting an ASO does not spawn a new thread. Don't forget that every
request is one thread, so it doesn't make much sense to use a new
thread to deal with ASOs, as they're going to be used in the request
processing.
For me :), the biggest questions is why would you want to insert a
delay in ASOs?
If this is true then what happens after Thread.sleep is active, and the next
user asks for his/her ASO? does a new thread spawn? or is there a lag?
A lag.
--
Thiago
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: IoC question - introducing a time delay in an ASO
On Wed, Feb 11, 2009 at 9:49 AM, Peter Stavrinides p.stavrini...@albourne.com wrote: I use an ASO as a token when signing users in, I use this small method to introduce a time delay (if there are multiple failed attempts, I increase the delay): Your code doesn't delay the ASO, it delays the request processing. ;) It prevents dictionary attacks against passwords, something everyone should do. I haven't tested it much, but it seems to work great, I was just a bit worried if it would be thread safe or if I was doing something stupid. ApplicationStateManager (the Tapestry service that handles ASOs) is already thread-safe (it uses ConcurrentHashMap), so I guess you don't need to worry. ;) -- Thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: IoC question - introducing a time delay in an ASO
On Wed, Feb 11, 2009 at 10:46 AM, James Sherwood jsherw...@rgisolutions.com wrote: Hello, Hi! Doesn't most dictionary style attacks create a new request each time therefore creating a new ASO? Kind of like closing your browser and reopening it each time? They are done by bots (programs), not people, so I guess you're right. If not this is a much better idea than mine of delaying the IP. Your code was not delaying the IP, it was delaying the session. It's not the same. Implement it using an application-wide map ip, login attempts instead of relying on an ASO. This has another advantage: you don't create a session when you don't need to. -- Thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
RE: IoC question - introducing a time delay in an ASO
Hello, Doesn't most dictionary style attacks create a new request each time therefore creating a new ASO? Kind of like closing your browser and reopening it each time? If not this is a much better idea than mine of delaying the IP. --James -Original Message- From: Thiago H. de Paula Figueiredo [mailto:thiag...@gmail.com] Sent: February-11-09 8:14 AM To: Tapestry users Subject: Re: IoC question - introducing a time delay in an ASO On Wed, Feb 11, 2009 at 9:49 AM, Peter Stavrinides p.stavrini...@albourne.com wrote: I use an ASO as a token when signing users in, I use this small method to introduce a time delay (if there are multiple failed attempts, I increase the delay): Your code doesn't delay the ASO, it delays the request processing. ;) It prevents dictionary attacks against passwords, something everyone should do. I haven't tested it much, but it seems to work great, I was just a bit worried if it would be thread safe or if I was doing something stupid. ApplicationStateManager (the Tapestry service that handles ASOs) is already thread-safe (it uses ConcurrentHashMap), so I guess you don't need to worry. ;) -- Thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
RE: IoC question - introducing a time delay in an ASO
Hello, I am not him:)(if that makes sense:) but I am doing the same thing right now. I am using the database not to slow connections but block IP's that get 100 failed login attempts over 2 minutes(blocked for 1 hour). I like your idea of a map held in memory much better. But how do I create an application wide map(object) in T5? Sorry for kind of hijacking your thread Peter:) --James -Original Message- From: Thiago H. de Paula Figueiredo [mailto:thiag...@gmail.com] Sent: February-11-09 8:52 AM To: Tapestry users Subject: Re: IoC question - introducing a time delay in an ASO On Wed, Feb 11, 2009 at 10:46 AM, James Sherwood jsherw...@rgisolutions.com wrote: Hello, Hi! Doesn't most dictionary style attacks create a new request each time therefore creating a new ASO? Kind of like closing your browser and reopening it each time? They are done by bots (programs), not people, so I guess you're right. If not this is a much better idea than mine of delaying the IP. Your code was not delaying the IP, it was delaying the session. It's not the same. Implement it using an application-wide map ip, login attempts instead of relying on an ASO. This has another advantage: you don't create a session when you don't need to. -- Thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: IoC question - introducing a time delay in an ASO
Something like a singleton tapestry service with an access-synchronized map inside maybe? Uli James Sherwood schrieb: Hello, I am not him:)(if that makes sense:) but I am doing the same thing right now. I am using the database not to slow connections but block IP's that get 100 failed login attempts over 2 minutes(blocked for 1 hour). I like your idea of a map held in memory much better. But how do I create an application wide map(object) in T5? Sorry for kind of hijacking your thread Peter:) --James -Original Message- From: Thiago H. de Paula Figueiredo [mailto:thiag...@gmail.com] Sent: February-11-09 8:52 AM To: Tapestry users Subject: Re: IoC question - introducing a time delay in an ASO On Wed, Feb 11, 2009 at 10:46 AM, James Sherwood jsherw...@rgisolutions.com wrote: Hello, Hi! Doesn't most dictionary style attacks create a new request each time therefore creating a new ASO? Kind of like closing your browser and reopening it each time? They are done by bots (programs), not people, so I guess you're right. If not this is a much better idea than mine of delaying the IP. Your code was not delaying the IP, it was delaying the session. It's not the same. Implement it using an application-wide map ip, login attempts instead of relying on an ASO. This has another advantage: you don't create a session when you don't need to. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: IoC question - introducing a time delay in an ASO
On Wed, Feb 11, 2009 at 11:16 AM, Ulrich Stärk u...@spielviel.de wrote: Something like a singleton tapestry service with an access-synchronized map inside maybe? That's what I'd do. James: sorry for mistaking your message as someone else's. :) -- Thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: IoC question - introducing a time delay in an ASO
What happens in a clustered environment? Tapestry services aren't part of normal HTTP session clustering. Olle 2009/2/11 Thiago H. de Paula Figueiredo thiag...@gmail.com On Wed, Feb 11, 2009 at 11:16 AM, Ulrich Stärk u...@spielviel.de wrote: Something like a singleton tapestry service with an access-synchronized map inside maybe? That's what I'd do. James: sorry for mistaking your message as someone else's. :) -- Thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Olle Hallin Senior Java Developer and Architect olle.hal...@crisp.se www.crisp.se
RE: IoC question - introducing a time delay in an ASO
Hello,
Thanks for the nudge in the right direction.
I created the service and I was wondering if you could have a look at how I
created it to be sure I've done it right(Everything seems to work fine but
it's my first service and I want to be sure it's done right):
Steps in reverse order basically:
Added to page:
@Inject
private FailedLoginPrevention flp;
Activate it:
binder.bind(FailedLoginPrevention.class, FailedLoginPreventionImpl.class);
Interface:
public interface FailedLoginPrevention {
int checkIP(String IP);
}
Implementation:
public class FailedLoginPreventionImpl implements FailedLoginPrevention {
public static MapString, FailedLoginPreventionHelper ipmap = new
HashMapString, FailedLoginPreventionHelper(); @Override public
synchronized int checkIP(String IP) {
if (FailedLoginPreventionImpl.ipmap.containsKey(IP)) {
// IP is there check last failed login
FailedLoginPreventionHelper flph = FailedLoginPreventionImpl.ipmap
.remove(IP);
Calendar now = Calendar.getInstance();
if ((now.getTimeInMillis() - flph.getLastcheck().getTimeInMillis())
(1000 * 60 * 60 * 5)) {// 5
//last failed login was more than 5 hours ago, reset the ip's time
// hours
flph.setTime(0);
} else {
flph.setTime(flph.getTime() * 2);
}
flph.setLastcheck(now);
FailedLoginPreventionImpl.ipmap.put(IP, flph);
return flph.getTime();
}
FailedLoginPreventionImpl.ipmap.put(IP, new
FailedLoginPreventionHelper());
return 0;
}
}
Helper Class:
public class FailedLoginPreventionHelper {
private int _time = 0;
private Calendar _lastcheck = Calendar.getInstance();
public int getTime() {
return _time;
}
public void setTime(int time) {
this._time = time;
}
public Calendar getLastcheck() {
return _lastcheck;
}
public void setLastcheck(Calendar lastcheck) {
this._lastcheck = lastcheck;
}
}
Thanks,
--James
-Original Message-
From: Thiago H. de Paula Figueiredo [mailto:thiag...@gmail.com]
Sent: February-11-09 9:18 AM
To: Tapestry users
Subject: Re: IoC question - introducing a time delay in an ASO
On Wed, Feb 11, 2009 at 11:16 AM, Ulrich Stärk u...@spielviel.de wrote:
Something like a singleton tapestry service with an access-synchronized
map
inside maybe?
That's what I'd do.
James: sorry for mistaking your message as someone else's. :)
--
Thiago
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: IoC question - introducing a time delay in an ASO
Thanks for the input Thiago and James, I have adjusted my implementation to use a singleton as James suggested :-) thanks! we ran a Perl script against it and it seems solid. I will stick it on the wiki for anyone interested. Cheers, Peter -- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Please visit http://www.albourne.com/email.html for important additional terms relating to this e-mail. - Original Message - From: James Sherwood jsherw...@rgisolutions.com To: Tapestry users users@tapestry.apache.org Sent: Wednesday, 11 February, 2009 15:07:33 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: RE: IoC question - introducing a time delay in an ASO Hello, I am not him:)(if that makes sense:) but I am doing the same thing right now. I am using the database not to slow connections but block IP's that get 100 failed login attempts over 2 minutes(blocked for 1 hour). I like your idea of a map held in memory much better. But how do I create an application wide map(object) in T5? Sorry for kind of hijacking your thread Peter:) --James -Original Message- From: Thiago H. de Paula Figueiredo [mailto:thiag...@gmail.com] Sent: February-11-09 8:52 AM To: Tapestry users Subject: Re: IoC question - introducing a time delay in an ASO On Wed, Feb 11, 2009 at 10:46 AM, James Sherwood jsherw...@rgisolutions.com wrote: Hello, Hi! Doesn't most dictionary style attacks create a new request each time therefore creating a new ASO? Kind of like closing your browser and reopening it each time? They are done by bots (programs), not people, so I guess you're right. If not this is a much better idea than mine of delaying the IP. Your code was not delaying the IP, it was delaying the session. It's not the same. Implement it using an application-wide map ip, login attempts instead of relying on an ASO. This has another advantage: you don't create a session when you don't need to. -- Thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
RE: IoC question - introducing a time delay in an ASO
Hello, I could be wrong but worse case it would just slow down the interval, how bad or at all would depend on how you have your barracuda(or whatever) set up(IP's route to same server)? Just a shot in the dark maybe:) --James -Original Message- From: Olle Hallin [mailto:olle.hal...@gmail.com] Sent: February-11-09 10:32 AM To: Tapestry users Subject: Re: IoC question - introducing a time delay in an ASO What happens in a clustered environment? Tapestry services aren't part of normal HTTP session clustering. Olle 2009/2/11 Thiago H. de Paula Figueiredo thiag...@gmail.com On Wed, Feb 11, 2009 at 11:16 AM, Ulrich Stärk u...@spielviel.de wrote: Something like a singleton tapestry service with an access-synchronized map inside maybe? That's what I'd do. James: sorry for mistaking your message as someone else's. :) -- Thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Olle Hallin Senior Java Developer and Architect olle.hal...@crisp.se www.crisp.se - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: IoC question - introducing a time delay in an ASO
Peter Stavrinides wrote: I use an ASO as a token when signing users in, I use this small method to introduce a time delay (if there are multiple failed attempts, I increase the delay): It would be an option to store server side when a person/system is allowed another try to login and assure all login attempts from that IP address fail until that time has passed. This would protect you against trying to login from different browser sessions. As you would need a way to identify the source of the login, the IP address is all you have, so that can still be forged. But at least you are making it more difficult for the hacker to try many possibilities. Kind regards, Joachim -- Joachim Van der Auwera PROGS bvba, progs.be - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: IoC question - introducing a time delay in an ASO
I have added a page to the wiki, I will probably update it a bit still as I continue to modify this service: http://wiki.apache.org/tapestry/Tapestry5HowToMitigatingLoginAttacks Comments and suggestions encouraged! Peter - Original Message - From: Joachim Van der Auwera joac...@progs.be To: Tapestry users users@tapestry.apache.org Sent: Wednesday, 11 February, 2009 17:57:20 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: IoC question - introducing a time delay in an ASO Peter Stavrinides wrote: I use an ASO as a token when signing users in, I use this small method to introduce a time delay (if there are multiple failed attempts, I increase the delay): It would be an option to store server side when a person/system is allowed another try to login and assure all login attempts from that IP address fail until that time has passed. This would protect you against trying to login from different browser sessions. As you would need a way to identify the source of the login, the IP address is all you have, so that can still be forged. But at least you are making it more difficult for the hacker to try many possibilities. Kind regards, Joachim -- Joachim Van der Auwera PROGS bvba, progs.be - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
