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

Hi there,

After submitting a form, within 2 input elements (ie. op and period), to a custom TCL file, the very first line within the script is auth::require_login core ad_proc.

Thus, the script requires the user to be logged in order to continue the execution, receive both variables, and process those.

The script works as expected when the user is already logged. IT receives both variables properly and its execution goes 'until the end.

However, if the user is not logged, it gets redirected to the login page and, only one variable is passed through the link into the parameter return_url. As in the example below, where the second variable "op" is missing.

https://evex.co/register/index?token_ci=2bca8cd092d47f11a9d7d48501a75491&return_url=/items/item-add?period=12

It seems auth::require_login accepts only on one variable and others get are left behind.

Debbuging further and reading auth:require_login (i), on /api-doc, I've noticed that return_url is formed within another ad_proc, ad_get_login_url (ii).

i) api-doc/proc-view?proc=auth::require_login&source_p=1, line 50 within the file packages/acs-authentication/tcl/authentication-procs.tcl,

(ii) api-doc/proc-view?source_p=1&proc=ad_get_login_url&version_id= , implemented within he file packages/acs-tcl/tcl/security-procs.tcl, line 704

As those are core procs, I decided to share this question here in the forum.

Is this a bug within ad_get_login_url and how variable return_url gets assigned?

If not, How would I change my code to be able to receive both variables, after login procedure?

Best wishes,

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.

Brian

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,
I

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 OpenACS.org, 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 https://openacs.org/api-doc/proc-view?proc=ad_return_url&source_p=1 ?

I'll investigate some more.
Brian

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 https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers ), 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.

Brian

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,
I

Hi Iuri

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

thanks
Brian

I tried to reproduce the problem with the form/script below (placed in www), but everything works correctly for me with the HEAD version (in logged-in and logged-out state). Can you check the results with this script on your installation?

Form:

<html> <head><title>Iuri form</title></head>
<body>
<h1>Enter some values</h1>
<form action="/iuri.tcl" method="POST">
<input type="string" name="op" value="a">
<input type="string" name="period" value="b">
<input type="submit">
</form>
</body> </html>

Script (iuri.tcl):

auth::require_login
ns_return 200 text/plain [export_entire_form_as_url_vars]

Result (in browser):

op=a&period=b
Hi Gustaf

thanks for this. I mentioned in another comment that we have the kernel parameter RegisterRestrictEntireServerToRegisteredUsersFilters set to 1. In our case, when I place your script in a directory under /packages, it loses the form parameters when logged out i.e. after logging back in, it redirects to iuri.tcl? (with no params).

I tried this too in a recent OpenACS version, with RegisterRestrictEntireServerToRegisteredUsersFilters set to 1, and I still get the problem.

regards
Brian

Hi Brian,

Sorry for delay. Here's the piece of code (palliative) that I added to my script in order to make it work. (i.e. Passing arguments from one page to another, with login authentication in the middle)

ad_set_cookie -replace "t" -path "/" op $id
ad_set_cookie -replace "t" -path "/" period $period

Once that is executed in the previous page (before login auth), both variables are stored in the session. And later on, in the next page, and after login auth, I grab them and destroy the session

# Unset vars from sesssion
ad_unset_cookie op
ad_unset_cookie period

Gustaf,
Indeed, I need to upgrade my instance to the latest code. I haven't done it yet, because I forked a few notifications (to recover password and register confirmation), thus I need to replace them into a new custom pkg (outside acs-authentication).

Best wishes,
I

Dear Iuri,

i could reproduce the problem of the form with RegisterRestrictEntireServerToRegisteredUsersFilters is activated, The problem seems to be like since since ages (at least 14 years+). When this parameter is set, a filter named "ad_restrict_entire_server_to_registered_users" is registered, which is pretty invasive and tries to do what auth::require_login does. This is at least my understanding. However, it just respects query variables, but ignores form variables.

Anyhow, I've replaced the magic redirect call with "auth::require_login", and now it seems to work fine. The modified function is now [2] . Iuri, please test as well.

Does anyone know, what packages uses "*/user_please_login.tcl"? This name/pattern is probably some legacy and should be removed.

-gn

[1] http://fisheye.openacs.org/changelog/OpenACS?cs=MAIN%3Agustafn%3A20190115183056
[2] https://openacs.org/api-doc/proc-view?source_p=1&proc=ad_restrict_entire_server_to_registered_users

Hi Gustaf

thanks for this. It seems to even support file uploads, which is more than I had hoped for.

Brian