Forum OpenACS Q&A: 'only urls without a host name are permitted'

Why?

I get this message whenever I am redirected to the login screen.

For info:

- The system is set to allow log-in only over https
- In order to achieve that I have an http listener listening on port 8000 (for example), and an https listener on port 8443. When a link is selected that requires a quick visit to the register/login page, the following messsage appears: "only urls without a host name are permitted". The redirect after login then fails.

Because for login I am redirecting the session from port 8000 to port 8443, I have to specify the full https://xxx.xxx.xxx.xxx:8443/register/
url specified.

Why is the code written to baulk at full return addresses?

What is the best way to deactiate that check?

Regards
Richard

Collapse
Posted by Dave Bauer on
You don't want to deactivate it!

That is a security issue, someone can pass in a return_url to a different site.

So you need to debug your configuration.

What version of OpenACS are you using? It should work with port 8000/8443.

The code is in security::locations in acs-tcl/tcl/security-procs.tcl.

This procedure checks the http port configured for nssock and nsopenssl and should correctly figure out the urls from there.

Collapse
Posted by Torben Brosten on
Hi Richard,

Make sure you have the kernel parameter ForceHostP set to 1 when using ssl. This avoids situations where users have to login twice during a session (which happens when switching between domain and www.domain urls with https).

security::locations uses the domain that is configured in the config.tcl file. The domain needs to be consistent with it (and so assumes ForceHostP is set to 1 for secure connections.)

Also, use a recent version of the config.tcl file to make sure that the config settings are available for security::locations.

cheers,

Torben

Collapse
Posted by Richard Hamilton on
Dave, Torben, Thank you very much for the replies.

Torben, I restrict login to https which avoids the doube sign-in issue and prevents sending of cleartext passwords.

I have a heavily customised config.tcl file that I spent ages on so I will have to trawl through and look for any omissions against a new example file.

You are almost certainly right that this is a case of misguided misconfiguration! 😊

I'll have another go.

Collapse
Posted by Richard Hamilton on
No, its no use - I'm now confused!

If I type in www.server.com and go to /register, the system redirects to https on the servure port with no problem.

If however I select a link to a protected location (i.e. /admin), then I get the aforementioned error.

The error appears:

i) when no return url has been passed
ii) when a fully qualified return url has been passed.

In the config.tcl file ns_param hostname is set to the same as the non-sevure hostname - www.server.com and ns_param address is set to the IP address.

What determines the return url to be applied when an internal redirect is issued to force a log-in?

R.

Collapse
Posted by Torben Brosten on
There are only a few places that security::locations grabs data from config.tcl.

You might save some time by looking at the references to configuration info in the code first.

cheers,

Torben

Collapse
Posted by Dave Bauer on
Ah this is easy to fix!

I think you just need to find the code that is doing the HTTPS redirect. If you are generated the url internally without user supplied data you can pass a switch to ad_returnredirect.

If you can find that code maybe we can just fix it there.

Collapse
Posted by Torben Brosten on
Try adding an ns_log statement to the end of security::locations

ns_log Notice "security::locations, locations: $locations"

Reload via APM and then try again.

Check your domain url against the values provided (and shown in the log), specifically the value closest to the one you are having problems with.

That should indicate where the offending data is (hopefully)!

cheers,

Torben

Collapse
Posted by Richard Hamilton on
OK, sorry for the delay. I have now had a bit of time to look at this and have found an issue. Not yet sure if it is THE issue but it nevertheless is AN issue! 😊

In my config.tcl file I have used the naming scheme recommended in the Aolserver and nsopenssl docs rather than the openacs sample which is what has thrown this up.

v4.5 of AOlserver supports virtual servers in a single config.tcl and consequently I have set my nsopenssl contexts up as:

vs1_users_ctx
vs1_admins_ctx
vs1_clients_ctx

The reason for doing this is that if you want to have a single AOlserver instance running multiple sites with listeners specific to each site, you can do that by specifying for example:

vs2_users_ctx
vs2_admins_ctx
vs2_clients_ctx

...and so on ad infinitum!

The security::locations proc however has the nsopenssl context hard-coded into it as 'users'. Thus is will never find my configured listener from the config file.

Now I can fix this by hacking security::locations, but I really don't think that openacs should be imposing arbitrary context descriptions. The contexts are declared in the config.tcl before being used and I think this proc should be re-written to read the declared contexts rather than guess.

What do people think?

As an aside, there is a simple typo in the declaration of secure_port in this proc which appears as 'set secure_post' which may not help matters either.

R.

Collapse
Posted by Torben Brosten on
The arbitrary use of "users" is essentially hard coded in config.tcl There are other procs that depend on this context as well.

The use of context "users" was established as the standard context for OpenACS by matter of requiring a consistent, single context to be backwards compatible with other procs that use nsopenssl.

I'm all for having the entire config.tcl upgraded to handle multiple virtual servers, and the affected procs adjusted accordingly.

Once done I would be glad to help upgrade config.tcl to be more flexible in choosing file names and directory designations that adapt readily to various file hierarchy standards.

Collapse
Posted by Richard Hamilton on
Torben,

Thanks for the reply. I didn't know that other scripts relied on that context as well. Sounds like changing that could cause a total nightmare! :-|

Certainly, setting the context to 'users' has solved both of the problems ( i.e. 1. failure to re-direct to https, and 2. warning about complete urls not being permitted) so in that respect at least I am a happy bunny again.

I suppose there is no absolute need to have seperate listeners for Aolserver virtual servers since a single instance of Aolserver could handle any number of virtual domains using a single listener on a single https port anyway. If we wanted to use the outgoing context (i.e. for an ecommerce payment gateway), there is nothing to stop us configuring any number of additional named contexts for the purpose.

Perhaps someone much more knowledgeable than me would know whether there are memory and resource benefits to having a listener per domain for Aolserver virtual servers? For my own part I prefer to run a server for each OpenACS anyway so that I can shutdown and restart each domain without affecting any others. In other words, I probably wouldn't use the feature myself!

This probably comes under the category of nice to do from a philosophical point of view, but lots of work to no great benefit! Nevertheless, I would be happy to help and contribute if a consensus emerges. I set my config.tcl up according to the Aolserver docs and I think the onus would be on the OpenACS code to correctly inspect the config data for the context declaration using ns_config rather than making naming assumptions.

In any case we probably ought to check that somewhere it is documented that this nsopenssl context is currently hard-coded as 'users'.

Also, one of the kernel maintainers will need to update security::locations to correct the typo I found.

Best Regards
Richard

Collapse
Posted by Torben Brosten on
I believe that typo is fixed on cvs head. Maybe the fix didn't get into the last release in time..

With host node mapping it's possible a server could use multiple ssl ports and security certificates (one per subdomain for instance), but host node mapping is a bit buggy at this point. Definitely some flexibility to work toward.

cheers!

Torben