It's for a more secure process, the new session_id should be sent via ssl as well, and more still the logged in user should stay ssl.
The. Idea is that Dr. Evil who knows the value of the (unauthenticated) session_id at time_a shouldn't be able to operate as the logged in user at time_b by replaying the same value.
It all depends how your app works, but you must use some kind of persistent data store: gears, cookies, sessions, silverlight(spit), so you will need an identifier and this I'd should be as secure as you can get it, although ultimately there's no answer.
Sent from my BlackBerry® wireless device
-----Original Message-----
From: Tracy12 <j_lalith@xxxxxxxxx>
Date: Tue, 13 May 2008 23:16:45
To:users@xxxxxxxxxxxxxxxx
Subject: Re: Is this a know issue
Thanks for the reply,
I do not fully agree on what you say, why should I redirect and start a new
session. What I am doing is
inside the Authentication Hanlder I do the authentication and if success
full I return the constant OK if not FORBIDDEN.
How the the Auth handler get invoked is via a Location directive eg.show
below
The issue I have is printParam.pl does not print the POST parameters but it
prints the GET parameter.
I am using apache 2.2 with mod_perl 2.x
Whay it is working for get and not for post what is the workaround for this.
<Location /testURL>
PerlOptions +GlobalRequest
RequestHeader add MyHeader2 "%D %t"
AuthType TEST
AuthName "TEST1"
PerlAuthenHandler Test->authen_handler
....
.....
PerlSetVar errorURL "http://localhost/error.html";
Require valid-user
</Location>
#following script will print the REMOTE_USER ENV variable
Alias /testURL "/var/www/html/test/printParam.pl"
matt.farey wrote:
>
> Usually an authentication handler will send the user_agent a redirect
> header (for security) and start a new session on success, this handler
> could save parts of the POST payload against that session (remember to
> filter this data) so that when the user_agent makes the GET request to the
> new URL the session_id is transmitted and your application can access the
> session data, any make changes to the response: "hi filtered(_user_),
> haven't seen you since filtered(_db_lookup_)".
> In other words your handler should lookup the supplied POST credentials in
> db saving the data retrieved from the db (perhaps last login, email
> address ...) to a new session, and only then send the redirect (302)
>
> Sent from my BlackBerry® wireless device
>
> -----Original Message-----
> From: Tracy12 <j_lalith@xxxxxxxxx>
>
> Date: Tue, 13 May 2008 20:21:01
> To:users@xxxxxxxxxxxxxxxx
> Subject: Is this a know issue
>
>
> Hi,
>
> We have Apache Auth handler writting in mod_perl, after success full
> authentication (after the execution of auth handler).
>
> The request parameter came as POST data is lost, but if I send the same
> parameters with GET those are available.
>
> What is the reason for this, and how to preserve the post data came in and
> use in subequent processes after the execution of auth hanlder.
>
> Waiting for a early reploy
> Thanks
> --
> View this message in context:
> http://www.nabble.com/Is-this-a-know-issue-tp17222678p17222678.html
> Sent from the Apache HTTP Server - Users mailing list archive at
> Nabble.com.
>
>
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
> " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
>
>
>
--
View this message in context: http://www.nabble.com/Is-this-a-know-issue-tp17222678p17224085.html
Sent from the Apache HTTP Server - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|