Forum OpenACS Development: Re: returning to a url after execution of auth::require_login

Hi Iuri

by complete coincidence, I've been looking at exactly the same issue. The documentation for ad_get_login_url states that "All variables in ns_getform (both posts and gets) will be maintained", but it doesn't appear to be correctly working for me. I'm not running latest OpenACS though, so I don't know if it's an issue in latest version.


Hi Brian,

lol! Reading your words caused me a relief! My name's on the last 8 threads or more, in this Forum. I was wondering if I was alone... :)

My instance runs:

provides url="acs-kernel" version="5.9.1d17"

HEAD's on version 5.10 already, and I ran a DIFF comparing files /packages/acs-tcl/tcl/security-procs.tcl and /packages/acs-authentication/tcl/aithentication-procs.tcl .

There were several modifications. I posted some examples below, where the amends were applied precisely at [ad_get_login_url], and affect directly the URL and RETURN_URL assignments.

Based on that, we better upgrade our instances!

+ if {$host_node_id == 0} {
+ unset host_node_id
- ns_log $::security::log(login_url) "ad_get_login_url: final login_url <$url>"
+ set url [export_vars -base $url -no_empty {authority_id username return_url host_node_id}]
+ ::security::log login_url "ad_get_login_url: final login_url <$url>"

provides url="acs-tcl" version="5.10.0d21"/

I won’t doubt we will read from Gustaf soon! Something like “solution has been applied in the release …",

Best wishes,

Yeah, there's still a few of us around here - you're not alone! We're running an older version of OpenACS so often there's not much need for me to post questions here, but I still read every day. Recently there haven't been many emails coming from, but maybe that was related to a problem with the server?

Anyway, I think I found the cause of the problem (at least for my case, maybe not for your case). We have kernel parameter RegisterRestrictEntireServerToRegisteredUsersFilters set to 1. In ad_restrict_entire_server_to_registered_users there is this line:

ad_returnredirect "[subsite::get_element -element url]register/?return_url=[ns_urlencode [ad_conn url]?[ad_conn query]]"

As you can see it creates a return_url of [ad_conn url]?[ad_conn query], which won't work with a POST. Maybe it could be changed to use something like this ?

I'll investigate some more.

Ok, because of the fundamental differences between GET and POST, even using ad_return_url isn't going to fix the redirect issue in every case. For instance, if the form has a file upload widget, or you reach the length limit of a URL (around 2000 chars in IE ), it will break.

Having said that, it is an improvement on what is currently there. So, if you are confident that you don't have file uploads or lots of large fields that would put your over the URL length limits, you could try it, as a short term measure.

A more complete solution to the problem would be to implement some way to store the form data in Naviserver, and after the login redirect, recover the data. I'm not quite sure what the best approach to this would be. Would be good to get opinions from others here.


Hi Brian,

I've implemented the last option (Having NS to store temporarily), persisting both values in a session (different from the one, created by the OACS login authentication).

Then, in the next page, I get both values and destroy the session. That's a paliative "ugly" solution, to be in place while I figure out a better one. ( I need to upgrade my instance to the latest OACS source, in order to start writing better solution)

Best wishes,

Hi Iuri

could you post your code? I'm curious to see how you implemented it?