Typically when my Guards authenticate or authorize, they have some means of
counting failures for a given principal, and for a given origin IP or range.
When the failure count exceeds a safe level, the Guard locks out that
account or origin, returning a fast permission-denied for a period of time.
I've got another thing to throw in to this problem. So our reqs changed and
now we need to also specify a person id type in the url, e.g.
http://localhost:8182/lastRiskEval/{personid}/{personidtype}
So how do I attach to the router so that all of these patterns would match to
the single resour
Thanks Rob..Can u plz elaborate what do u mean by
backed off timeouts for authentication failures. What else
do u suggest for application level prevention for DOS attacks?
Hello,
I'm investigating restlet and would like to use the Entry class from
org.restlet.ext.atom package, but I just couldn't see this package in
the maven repo?
Have I missed somehing or is it intentional?
Thank you
Zsolt
My personal design style is that I only put application-layer protections in
the application -- e.g. backed off timeouts for authentication failures,
etc. Network level stuff I leave up to the OS or a dedicated proxy or
hardware firewall. Good firewalls -- heck, even the Linux kernel -- can in
fa
Its an open ended general questions and i want to discuss before
we start implementing anything.
As far as my knowledge goes by using firewalls we can only
detect network level attacks such as TCP SYN attacks or
malformed packet floods. I also know that there is no way
that the hardware can anal
I feel like part of the debate results from the contract of
Request.getResourceRef() being unclear. There seem to be at least two
differences of opinion in common circulation:
1) - getResourceRef() is returning the reference of the resource *as
originally requested* by the client.
OR
2) - getReso
On Fri, May 16, 2008 at 12:56 PM, Stephan Koops <[EMAIL PROTECTED]> wrote:
> Hi Alex,
>>
>> I now strongly believe that the TunnelService needs to be off by default.
>>
>
> do you used the most actual version? The extension tunnel is off by default
> now.
I just build from the trunk a few minutes
Very cleraly stated, thank you Jerome!
Hi Alex,
I now strongly believe that the TunnelService needs to be off by default.
do you used the most actual version? The extension tunnel is off by
default now.
* the resource reference should remain the same regardless of
whether such filters are enabled.
IMO no. It is the sense
I now strongly believe that the TunnelService needs to be off by default.
I've had to go into *every* single class that extends Application and add
this line to my constructor:
getTunnelService().setEnabled(false);
All of my code is now breaking wherever there is a resource with
an exte
On Wed, May 14, 2008 at 8:49 AM, Jerome Louvel <[EMAIL PROTECTED]> wrote:
>
> Hi Jean-Yves,
>
> We have looked into this in the past. The issue with the manual upload
> process is that is takes time on our side and on Maven's side (they talk
> about four weeks to get an upload request processed).
Hi Stephan,
If the request was authenticated using a client certificate, the
following will be non-null:
List certificates =
(List)getRequest().getAttributes().get("org.restlet.https.clientCertificates");
I believe this should now work with all types of HTTPS connectors in
Restlet, inclu
Ah, I think one of our users created a custom XMLBeansRepresentation that does
not have the size, and thus was not working using the method below. I ended up
checking for the entity size manually to get around this issue. I may have him
look at the implementation of the StringRepresentation to
Hi Bruno and all,
JAX-RS has a method in the API, where the application developer could
request, which authenticaton scheme was used
(SecurityContext.getAuthenticationScheme(), if someone is interested)
If the request was authenticated by BASIC, DIGEST, client certificate or
Servlet form authe
Hi Sam,
If you use the StringRepresentation for your POSTed entity, then you can be
sure that the size will known by the server. It is very easy for the
StringRepresentation to know this information and pass it along, which is
not true for more dynamic representations where buffering would be
nec
That's the right idea. What is the symptom of it not working? 404 not
found? Does the log show any evidence of Directory being invoked at all?
Another issue I've run into sometimes is that the resources aren't
available from the thread's classloader. You may need clap://system or
change how yo
17 matches
Mail list logo
