Hi Christopher,

On Wed, November 11, 2009 10:07 pm, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> John,
>
> On 11/11/2009 2:11 PM, John Morrison wrote:
>> 1) The referer must be XXX (configurable)
>> 2) There must be a token passed either GET or POST in the URL which
>> matches some internally generated code.
>
> I agree with Mark: a relatively simple Filter could be implemented that
> prohibits access unless the above requirements are met.
>
> These requirements don't really authenticate the user in any way, do
> they? Do you have to populate a Principal object in the request and then
> use that to do authorization? Or, do you just need to prevent
> unauthorized people from getting in?

Correct, at the moment there is no requirement to actually authenticate
the user.  However, I've been told to ensure that, if the client wishes
(and pays) that the solution could be expanded to do so.

Is this something like you are thinking;

If the user has a session;
  let them access what they want
else if the requested url has a param/value of [insert hash algor]
  set the user up with a session and let them access what they want
else
  return Access Forbidden

Is this possible in a filter?  (My knowledge of them is currently 0; I'll
read up on them in depth tomorrow)

>> I've been looking at this, and I *think* that I need to add a JAAS
>> realm,
>> but I can't work out how to not have a login page.  The security must
>> deny
>> access unless the above is matched.
>>
>> I've seen reference to where auth-method can be NONE which I assume is
>> right (since none of the others are) but am at a loss as to how to get
>> this to work.
>
> You could always make your login page just look like a "Forbidden" page.
> There's nothing that says a login page has to contain a login form :)

*grin* point, however doesn't the login page get displayed before the
LoginModule is called?

It's been a long time since I was active in the Apache world and I'm
afraid my Java skills are well out of date.  Please be patient.

Regards,

John.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to