-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
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
-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
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 tryin
-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
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 discriminator
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 tomcat
> From: Pid [mailto:p...@pidster.com]
> Subject: [OT] Re: interaction between .forward() and
> 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 ou
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 t
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 p
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 confidenti
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
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 net,
tenu fourni.
> Date: Sun, 5 Sep 2010 00:23:51 +0100
> From: ma...@apache.org
> To: users@tomcat.apache.org
> Subject: Re: interaction between .forward() and
>
> On 04/09/2010 17:27, André Warnier wrote:
> > Digest authentication is not very popular, and rather a pain t
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 n
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
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.
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 plain
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
> From: Brian McBride [mailto:bwm.topmea...@googlemail.com]
> Subject: interaction between .forward() and
> I want to have no authorization constraint because some resources have
> public access and no authentication is required for access to those
> resources.
Declarat
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
ac
21 matches
Mail list logo
