Forum OpenACS Q&A: Re: Question about linking to other acs site nodes

ad_returnredirect changed to a by default secure version in OpenACS 5.5 (I think.)

See: http://www.openacs.org/api-doc/proc-view?proc=ad_returnredirect

-allow_complete_url (boolean) (optional)
By default we disallow redirecting to urls outside the current host. This is based on the currently set host header or the host name in the config file if there is no host header. Set allow_complete_url if you are redirecting to a known safe external web site. This prevents redirecting to a site by URL query hacking.

Only use allow_complete_url on data from your database don't even pass unsanitized data from a URL or POST variable to that to prevent problems.

The error message is not really helpful.

error "Redirction to external hosts is not allowed."

It is allowed if the programmer specifically specifies it.

Oh dear, not so fast Ricky!

The redirector is using 'returnredirect' rather than 'ad_returnredirect'.

My foolish attempt to substitute ad_returnredirect resulted in:

"::882: unable to dispatch method 'ad_returnredirect'"

....because it clearly isn't a method!

Am I correct in thinking that 'returnredirect' is a method of the package object? It clearly doesn't accept the -allow_complete_url flag so for the time being I'm stumped again!

R.

the "allow_complete_url" option is intentionally not included, since it is an evil security problem.

The point of using such forms is that one can enter easily links (or menu-entries in your case) without having to write HTML/CSS/JS .... this increased convenience is mostly for end-users, which are normally not aware of security implications, or which are so many, such that a site-wide-admin or a package-admin can't trust all of them. The evil part of redirects is that a user sees a link to a trusted site, but it might direct him to a maybe same-looking fake-site setup for a phishing attack.

So, supporting the flag by default is definitely not a good idea. One could add a parameter in the form definition to allow insecure redirects, but since the form-definitions are as well designed in a way that the user cannot break the system, this does not help, when end-users are allowed to enter/change forms. So a possible path is add a policy which specifies, who is allowed to enter insecure field definitions and extend the form-validator to check these.

but maybe, there are other solutions as well.

Not so fast!! Whilst this worked fine on the current repository version, but the HEAD version that I checked-out yesterday converts tag characters such as the '<' to the &xx; code equivalent to prevent the entered value being used as HTML.

I therefore can't enter HTML into the xowiki::Formpage title field any more which prevents me using this to link from the menu.

I can't think of any other way of doing this from within xowiki itself, so my next plan is to recreate the redirector class previously discussed to redirect to a redirect.tcl in the site root that contains a call to ad_returnredirect.

This will be a double internal redirect which I am uncomfortable with.

Can anyone point me in the direction of a better way of doing this?

Regards
Richard

Richard, nobody hinders you to use on your site e.g.

  redirect instproc pretty_value {v} {
    ad_returnredirect -allow_complete_url $v
    ad_script_abort
  }

instead of the version based on the returnredirect method sketched earlier. However, i am not in favor of adding this variant to CVS because of the abuse potential. A good solution (see above) would require more effort than i can spend right now.

In case someone wonders, why my first version was using the returnredirect method rather than the ad_returnredirect function: The xo*-method be used outside of a connection thread while ad_returnredirect requires to be executed in a connection thread. Therefore, the method can be used safely e.g. in a regression test or in a scheduled procedure, etc. Allowing the title-field to contain HTML markup (which is rendered without escaping) must have been a bug in some earlier xowiki versions.