-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian,
I'm fumbling about seeking the hardness knob that controls my
thinking ... I know its there somewhere ... :)
Me, too. You can never be too paranoid about authentication code.
I'm learning from the discussion on this list that DIGEST is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian,
On 9/12/2010 4:18 PM, Brian McBride wrote:
On 09/09/2010 19:47, Christopher Schultz wrote:
I'm sure there are some edge cases where an authenticated user might end
up looking like a guest, but you cna probably solve those.
That's a bit of
Hi Christopher,
On 13/09/2010 19:58, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
[...]
That's a bit of a worry. Can you say any more about the edge cases I
should be concerned about.
Well, if Tomcat intercepts a request in order to perform authentication,
then the filter
Hi Christopher
On 09/09/2010 19:47, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
[...]
Here's something you can do. Write a filter that you attach to URLs that
/are/ used for authentication, and then copy the user's username into
the session.
Yes, that's the approach I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian,
On 9/4/2010 11:42 AM, Brian McBride wrote:
On 04/09/2010 15:27, Jason Britton wrote:
I would look at a servlet filter to provide this sort of dynamic access
control.
That's what I'm doing. The filter needs to know the user id - and I was
Thanks to all who have responded. The advice and comments have been
very helpful.
For my application, the MIM vulnerability is a concern, so I expect to
be using HTTPS for at least some of the traffic. Next steps are to
clarify my confidentiality requirements and see what I can find on the
On 06/09/2010 16:04, Brian McBride wrote:
Thanks to all who have responded. The advice and comments have been
very helpful.
For my application, the MIM vulnerability is a concern, so I expect to
be using HTTPS for at least some of the traffic. Next steps are to
clarify my confidentiality
Pid wrote:
...
Assuming you're not running on hamster powered servers, yes, with modern
software hardware it's quite cheap.
I find this remark very discriminatory toward hamsters. What makes you think that
hamsters are worse than tomcats or penguins or even apples, he ?
We've got several
On 06/09/2010 17:51, André Warnier wrote:
Pid wrote:
...
Assuming you're not running on hamster powered servers, yes, with modern
software hardware it's quite cheap.
I find this remark very discriminatory toward hamsters. What makes you
think that hamsters are worse than tomcats or
From: Pid [mailto:p...@pidster.com]
Subject: [OT] Re: interaction between .forward() and security-constraint
An average sized camel won't fit inside the average
sized server chassis.
But it will fit on a stick.
Since we're completely off in the weeds, I'd like to point out that one
Pid wrote:
On 06/09/2010 17:51, André Warnier wrote:
Pid wrote:
...
Assuming you're not running on hamster powered servers, yes, with modern
software hardware it's quite cheap.
I find this remark very discriminatory toward hamsters. What makes you
think that hamsters are worse than
On 06/09/2010 20:26, André Warnier wrote:
Pid wrote:
On 06/09/2010 17:51, André Warnier wrote:
Pid wrote:
...
Assuming you're not running on hamster powered servers, yes, with
modern
software hardware it's quite cheap.
I find this remark very discriminatory toward hamsters. What makes
Mark Thomas wrote:
On 04/09/2010 17:27, André Warnier wrote:
Digest authentication is not very popular, and rather a pain to
implement yourself.
The reason why it is not very popular is that it is a bit of a halfway
solution : it does avoid user passwords to be transmitted in clear over
the
Hi,
I want to implement discretionary access control in an app running in
Tomcat - i.e. access controls on URLs served by Tomcat can be changed by
users. I expect to have a 1M resources each with its own ACL. Some
resources have 'public' access. No authentication should be required to
From: Brian McBride [mailto:bwm.topmea...@googlemail.com]
Subject: interaction between .forward() and security-constraint
I want to have no authorization constraint because some resources have
public access and no authentication is required for access to those
resources.
Declarative
I would look at a servlet filter to provide this sort of dynamic access
control. Map urls of your choosing to pass through this servlet filter, the
servlet filter could look up potentially changing list of access control
rules and route request to login page or whatever page you'd like if user is
Hi Charles,
Thanks for the quick answer.
On 04/09/2010 15:20, Caldarale, Charles R wrote:
[...]
Declarative security is intentionally static;
Its not the declarative access control I want to use - I'd have liked to
be able to resuse the authentication code ...
t
[...]
This is very
Hi Jason,
Thanks for the response.
On 04/09/2010 15:27, Jason Britton wrote:
I would look at a servlet filter to provide this sort of dynamic access
control.
That's what I'm doing. The filter needs to know the user id - and I was
hoping to resuse Tomcat's authentication mechanism for that.
Brian McBride wrote:
...
Ok - now to figure out how to implement digest authentication ...
Digest authentication is not very popular, and rather a pain to implement
yourself.
The reason why it is not very popular is that it is a bit of a halfway solution : it does
avoid user passwords to be
On 04/09/2010 17:27, André Warnier wrote:
Digest authentication is not very popular, and rather a pain to
implement yourself.
The reason why it is not very popular is that it is a bit of a halfway
solution : it does avoid user passwords to be transmitted in clear over
the net, but it is not
Sep 2010 00:23:51 +0100
From: ma...@apache.org
To: users@tomcat.apache.org
Subject: Re: interaction between .forward() and security-constraint
On 04/09/2010 17:27, André Warnier wrote:
Digest authentication is not very popular, and rather a pain to
implement yourself.
The reason why
21 matches
Mail list logo
