cross-session site_url interaction

I am reporting what appears to be a bug in the way MODx determines site_url.

Suppose we have a web site accessed at http://site.example.com/. And the secure URL at https://server.example.com/~joe/ maps to the same document root as
http://site.example.com/. So our MODx-generated web site can be accessed via either of these URLs:

http://site.example.com/
https://server.example.com/~joe/

Depending on which of the above URLs we use to access the web site, MODx calculates the correct value for site_url and everything works. A user visiting
via http://site.example.com/ sees all pages as residing below http://site.example.com/. A user visiting via https://server.example.com/~joe/
sees all pages residing below https://server.example.com/~joe/ .

Now suppose person A accesses the manager interface at the following URL:

https://server.example.com/~joe/manager/

and in parallel, at the same time, B accesses the web site at;

http://site.example.com/

Both people see the expected links, relative to the URL they are using.

Now while A is using the manager interface, A begins editing one of the documents, and clicks on the Preview tab and then clicks on Save and Refresh.

At this point, the manager interface is working just fine. But person B (who came via http://site.example.com/ ) now sees links relative to https://server.example.com/~joe/ instead.

Meanwhile, if A finishes editing the document, and then saves it, then B starts seeing all links related to http://site.example.com/ again.

If I make a page explicitly print the value of site_url, I can see that its value seen by user B changes depending on what user A is doing.

B sees the wrong site_url only while A is in the middle of editing a document and has done a Save-and-Refresh. So the problem is related to A editing a document, not to A being logged in. As soon as A has finished editing the document by doing a Save, B sees normal behavior, even though A remains logged in.

I did these tests using two different web browsers (Opera and Firefix) on the same workstation. For these tests I was not going through any proxy server. I got the same anomalous results with browser rules exchanged, i.e., A using Opera and B using Firefox, or B using Opera and A using Firefox.

Rahul

If you have pages meant to be accessed from multiple urls, make sure you are not caching any absolute URLs. Since we recommend using the base tag with the site_url setting in MODx templates, also make sure this is not cached. You would need to use a snippet to get the site_url using an non-cached snippet call (or simply don’t use cacheable pages)...

Example snippet to getSiteUrl:


In your template( s ) at the beginning of your HEAD tag:

Thank-you for the suggestions. I am not using site_url in any template or web page (other than just to print its value for debugging). I don’t have "base href" defined.

The links are generated by Wayfinder. When I do a view source as user B (who originally visited http;//www.example.com/), after user A has begin editing a document, links seen by B show up as something like this: <a href="/~joe/xyz.html"...>. Thus the link itself is wrong.

I will see if using "base href" as recommended, using an uncached value for site_url, helps. I will report back when done.

Quote from: crossconnect at Jan 27, 2009, 01:47 AM

The links are generated by Wayfinder. When I do a view source as user B (who originally visited http;//www.example.com/), after user A has begin editing a document, links seen by B show up as something like this: <a href="/~joe/xyz.html"...>. Thus the link itself is wrong.

In that case, make sure the Wayfinder calls are not cached as well. By default, Wayfinder generates links relative to the site root (which is established by the base href value if it exists).

Setting "base href" didn’t affect the situation, but setting Wayfinder (and also Breadcrumbs) to uncached, by enclosing within [!...!], solved the problem. Thanks again for the suggestions.