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

Collapse
Posted by Gustaf Neumann on
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.

Collapse
Posted by Richard Hamilton on
Well of course you're absolutely right! The most obvious method is to put the link into the xowiki::formpage title field.

I have just tried this and it works fine. Much simpler. I suppose I expected html title entries to be disallowed. But on reflection, this represents less of a risk, because the xowiki instance can be set to only allow certain parties to add formpages, and with page level permissions set it could even be restricted to only formpages of class redirect.

Thank you Gustaf for your guidance.

Is that the best way to do it, or can anyone think of a better or more elegant alternative?

Regards
Richard

Collapse
Posted by Richard Hamilton on
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

Collapse
Posted by Richard Hamilton on
In my previous post I mentioned creating a redirector class as per Gustaf's earlier instructions that links to a /redirect.tcl file that calls ad_returnredirect with the -allow_complete_url flag.

Whilst I think this will work ok I wonder if there is a better way than a double redirect.

Whilst thinking about the possibilities it ocurred to me that I could create a simple, standard xowiki::page that has an adp include as its only content. The tcl file associated with that adp include could contain simply the ad_returnredirect call, so the template would never actually be returned, and control would never pass back to the calling xowiki object.

Can I do this safely? Can I be sure that all the processes will end, or will I end up with processes waiting indefinitely for return values?

R.

Collapse
Posted by Gustaf Neumann on
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.

Collapse
Posted by Richard Hamilton on
Gustaf,

Thank you for taking the time to explain. I am working through the xotcl documentation and examples so hopefully I will be less clueless in the future! :-)

Regards
Richard