cookie crumbler - preserving variables in URL
I'm using cookie crumbler for authentication Often, the pages that require authentication have a variables on the end of the URL. http://www.site.org/updateListing_html?pid=22 After authentication, these variables get dropped generating an error for the dropped variable redirects to: http://www.site.org/updateListing_html How can I modify the cookie crumbler methods to pass these variables and redirect to the proper URL? thanks -- David
On Wed, Aug 18, 2004 at 06:39:38PM -0700, David Siedband wrote:
I'm using cookie crumbler for authentication
Often, the pages that require authentication have a variables on the end of the URL.
http://www.site.org/updateListing_html?pid=22
After authentication, these variables get dropped generating an error for the dropped variable
redirects to:
http://www.site.org/updateListing_html
How can I modify the cookie crumbler methods to pass these variables and redirect to the proper URL?
You might have a look at the just-released CMF 1.5 beta which contains a fix for this according to the changelog. http://zope.org/Products/CMF/CMF-1.5.0beta/CHANGES.txt -- Paul Winkler http://www.slinkp.com
David Siedband wrote:
How can I modify the cookie crumbler methods to pass these variables and redirect to the proper URL?
You'll have to patch CookieCrumbler so it does what you require :-S Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Am Donnerstag, 19. August 2004 03:39 schrieb David Siedband:
I'm using cookie crumbler for authentication
Often, the pages that require authentication have a variables on the end of the URL.
http://www.site.org/updateListing_html?pid=22
After authentication, these variables get dropped generating an error for the dropped variable
redirects to:
http://www.site.org/updateListing_html
How can I modify the cookie crumbler methods to pass these variables and redirect to the proper URL?
just as a hint without testing: the stock login_form that comes with cookiecrumbler sets a hidden-field "came_from" <input type="hidden" name="came_from" value="&dtml-came_from;"> which should carry the full url including the query_string; at least the source code does seem to imply this. You might want to check the html-source of your maybe modified login-form, or your logged_in method, that might be called from its action. Hope that helps a bit, Sascha
On Boomtime, Bureaucracy 13, 3170 YOLD, David Siedband wrote:
Often, the pages that require authentication have a variables on the end of the URL.
http://www.site.org/updateListing_html?pid=22
After authentication, these variables get dropped generating an error for the dropped variable
redirects to:
I have similar problem with traverse_subpath; I have ZPT, say http://server/Template, which I call as http://server/Template/Something and I read traverse_subpath in the template to render wanted output; when Unauthorized is raised, CookieCrumbler redirects to http://server/Template. It seems to use <offending_object>.absolute_url() instead of REQUEST.URL to redirect. I think I'll try to use Python script, which will call the ZPT, catch Unauthorized and redirect manually to /login/login_form?came_from=<correct_address>. It's surely a kludge, but easier to write and maintain through upgrades than patching CookieCrumbler. -- __ Maciek Pasternacki <maciekp@japhy.fnord.org> [ http://japhy.fnord.org/ ] `| _ |_\ / { Bullshit makes the flowers grow ,|{-}|}| }\/ & it's beautiful. } \/ |____/ ( Principia Discordia ) -><-
Maciek Pasternacki wrote:
I think I'll try to use Python script, which will call the ZPT, catch Unauthorized and redirect manually to /login/login_form?came_from=<correct_address>. It's surely a kludge, but easier to write and maintain through upgrades than patching CookieCrumbler.
Unless your patches get fed into a CookieCrumbler release ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Prickle-Prickle, Bureaucracy 15, 3170 YOLD, Chris Withers wrote:
I think I'll try to use Python script, which will call the ZPT, catch Unauthorized and redirect manually to /login/login_form?came_from=<correct_address>. It's surely a kludge, but easier to write and maintain through upgrades than patching CookieCrumbler.
Unless your patches get fed into a CookieCrumbler release ;-)
I don't feel I could write a patch that not only works for me, but also does the Right Thing in all circumstances, nor am I able to give it as much testing as it would need to make sure it won't cause breakage in some other situation. -- __ Maciek Pasternacki <maciekp@japhy.fnord.org> [ http://japhy.fnord.org/ ] `| _ |_\ / { ...so I talked about conscience, and I talked about pain, ,|{-}|}| }\/ and he looked out of window, and it started to rain, and \/ |____/ I thought, maybe - I've already gone crazy... } ( Fish ) -><-
Maciek Pasternacki wrote:
Unless your patches get fed into a CookieCrumbler release ;-)
I don't feel I could write a patch that not only works for me, but also does the Right Thing in all circumstances, nor am I able to give it as much testing as it would need to make sure it won't cause breakage in some other situation.
That's alright, submitting a patch means other people will review your code to, and make sure it's doing the "right thing" cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Hi, Am Do, den 19.08.2004 schrieb Maciek Pasternacki um 19:01:
On Boomtime, Bureaucracy 13, 3170 YOLD, David Siedband wrote:
Often, the pages that require authentication have a variables on the end of the URL.
http://www.site.org/updateListing_html?pid=22
After authentication, these variables get dropped generating an error for the dropped variable
redirects to:
I have similar problem with traverse_subpath; I have ZPT, say http://server/Template, which I call as http://server/Template/Something and I read traverse_subpath in the template to render wanted output; when Unauthorized is raised, CookieCrumbler redirects to http://server/Template. It seems to use <offending_object>.absolute_url() instead of REQUEST.URL to redirect.
I think I'll try to use Python script, which will call the ZPT, catch Unauthorized and redirect manually to /login/login_form?came_from=<correct_address>. It's surely a kludge, but easier to write and maintain through upgrades than patching CookieCrumbler.
Well. Whats wrong with just leaving the request/URL allone, and dont do any redirect but just check for authentication bring up the auth page in place? I never get it why almost all userfolders do redirects. Regards Tino
Maciek Pasternacki wrote at 2004-8-19 19:01 +0200:
... I have similar problem with traverse_subpath; I have ZPT, say http://server/Template, which I call as http://server/Template/Something and I read traverse_subpath in the template to render wanted output; when Unauthorized is raised, CookieCrumbler redirects to http://server/Template.
CookieCrumber's behaviour is controlled by the "came_from" variable that you can adjust to your needs in your "login_form". -- Dieter
On Setting Orange, Bureaucracy 16, 3170 YOLD, Dieter Maurer wrote:
... I have similar problem with traverse_subpath; I have ZPT, say http://server/Template, which I call as http://server/Template/Something and I read traverse_subpath in the template to render wanted output; when Unauthorized is raised, CookieCrumbler redirects to http://server/Template.
CookieCrumber's behaviour is controlled by the "came_from" variable that you can adjust to your needs in your "login_form".
In login_form I receive came_from from CookieCrumbler's Python code and it's set wrong. As far as I know I have no other means of getting URL of page that user was trying to view. Anyway, kludge with Python script raising Unauthorized (after allowing to import Unauthorized by scripts) seems to work well. -- __ Maciek Pasternacki <maciekp@japhy.fnord.org> [ http://japhy.fnord.org/ ] `| _ |_\ / { Any road followed to its end leads precisely nowhere. Climb ,|{-}|}| }\/ the mountain just a little to test it's a mountain. From the top \/ |____/ of the mountain you cannot see the mountain. } ( F.Herbert ) -><-
Maciek Pasternacki wrote at 2004-8-29 12:36 +0200:
On Setting Orange, Bureaucracy 16, 3170 YOLD, Dieter Maurer wrote:
... I have similar problem with traverse_subpath; I have ZPT, say http://server/Template, which I call as http://server/Template/Something and I read traverse_subpath in the template to render wanted output; when Unauthorized is raised, CookieCrumbler redirects to http://server/Template.
CookieCrumber's behaviour is controlled by the "came_from" variable that you can adjust to your needs in your "login_form".
In login_form I receive came_from from CookieCrumbler's Python code and it's set wrong.
But, you can make the corresponding hidden variable right: In the login form, you still have the original request. -- Dieter
On Prickle-Prickle, Bureaucracy 25, 3170 YOLD, Dieter Maurer wrote:
I have similar problem with traverse_subpath; I have ZPT, say http://server/Template, which I call as http://server/Template/Something and I read traverse_subpath in the template to render wanted output; when Unauthorized is raised, CookieCrumbler redirects to http://server/Template.
CookieCrumber's behaviour is controlled by the "came_from" variable that you can adjust to your needs in your "login_form".
In login_form I receive came_from from CookieCrumbler's Python code and it's set wrong.
But, you can make the corresponding hidden variable right:
In the login form, you still have the original request.
How is it possible? Login form is not displayed instead of called page under it's URL, but it's /login/login_form?came_from=..., so there must be some redirection and a new request. Tests with wget also suggest that login_form doesn't receive original request: #v+ japhy@lizard:~/z % wget -v --progress= http://www.localhost:8000/Personal --02:45:42-- http://www.localhost:8000/Personal => `Personal' Resolving www.localhost... 127.0.0.1 Connecting to www.localhost[127.0.0.1]:8000... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: http://www.localhost:8000/login/login_form?came_from=http%3A//www.localhost%... [following] --02:45:42-- http://www.localhost:8000/login/login_form?came_from=http%3A//www.localhost%... => `login_form?came_from=http:%2F%2Fwww.localhost:8000%2FPersonal&retry=&disable_cookie_login__=1.1' Connecting to www.localhost[127.0.0.1]:8000... connected. HTTP request sent, awaiting response... 200 OK #v- -- __ Maciek Pasternacki <maciekp@japhy.fnord.org> [ http://japhy.fnord.org/ ] `| _ |_\ / { ...you claimed all this time that you would die for me, ,|{-}|}| }\/ why then are you so surprised when you hear your own eulogy... } \/ |____/ ( M. J. Keenan ) -><-
Maciek Pasternacki wrote at 2004-9-1 02:48 +0200:
On Prickle-Prickle, Bureaucracy 25, 3170 YOLD, Dieter Maurer wrote:
... But, you can make the corresponding hidden variable right:
In the login form, you still have the original request.
How is it possible? Login form is not displayed instead of called page under it's URL, but it's /login/login_form?came_from=..., so there must be some redirection and a new request.
You are right! CookieCrumber uses "redirect" to activate its login form -- with an incomplete "came_from". Instead, it should probably render the login form. -- Dieter
On Setting Orange, Bureaucracy 26, 3170 YOLD, Dieter Maurer wrote:
CookieCrumber uses "redirect" to activate its login form -- with an incomplete "came_from".
Instead, it should probably render the login form.
Wouldn't it mess with proxies and caches? -- __ Maciek Pasternacki <maciekp@japhy.fnord.org> [ http://japhy.fnord.org/ ] `| _ |_\ / { ...elbow deep within the borderline, show me that you love me ,|{-}|}| }\/ and that we belong together; shoulder deep within the borderline, \/ |____/ relax, turn around and take my hand... } ( M. J. Keenan ) -><-
Hi, Am Mi, den 01.09.2004 schrieb Maciek Pasternacki um 22:42:
On Setting Orange, Bureaucracy 26, 3170 YOLD, Dieter Maurer wrote:
CookieCrumber uses "redirect" to activate its login form -- with an incomplete "came_from".
Instead, it should probably render the login form.
Wouldn't it mess with proxies and caches?
No difference in messing no matter if you provide the form in-request or return a redirect here. Its all the same process only different HTTP status. Danymic pages (e.g. after logged in) cannot be cached much. So if the login page is in the same place, it does not matter, but is very comfortable - you avoid ugly URLs, you avoid translating post variables to URL and a lot more. Regards Tino Wildenhain
Maciek Pasternacki wrote at 2004-9-1 22:42 +0200:
On Setting Orange, Bureaucracy 26, 3170 YOLD, Dieter Maurer wrote:
CookieCrumber uses "redirect" to activate its login form -- with an incomplete "came_from".
Instead, it should probably render the login form.
Wouldn't it mess with proxies and caches?
It could set the corresponding cache control headers. If it contained relative URLs, they might be resolved wrongly. But, this is a single page. You could avoid relative URLs there. -- Dieter
participants (7)
-
Chris Withers -
David Siedband -
Dieter Maurer -
Maciek Pasternacki -
Paul Winkler -
Sascha Ottolski -
Tino Wildenhain