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

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

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.

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.

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.

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