« Nice: unasked advertisement for panagenda MarvelClient | Main | Only two things I'd like to see improved in Flock - so far »

Fixing a host/domain issue in the AJAX Calendar Blogsphere Sideblock

by florian vogler :: 
Just discovered a problem with the Calendar sideblock (see Calendar on the right hand side of this blogs homepage) yesterday and fixed it as follows:

This blog is available from both
http://www.panagenda.com/pub/panablog.nsf" and "http://blog.panagenda.com(/pub/panablog.nsf)"
- the Calendar sideblock fetches its data through an XMLHttpRequest, which (for security reasons I would understand if it actually were different hosts) does not allow to fetch data across different domains. As I specified "http://blog.panagenda.com/pub/panablog.nsf" as the homepage URL in the blog(sphere) configuration, anyone opening the blog through http://www.panagenda.com would get an error (silent or a messagebox even) "Permission denied".

To fix this, I opened the page "Javascript - AJAX Calendar|script/calendar.js". The problem is in the two computed text objects, that read the source URL for the calendar content from the blogsphere configuration - this needs to be adjusted to read the content from the host you actually open the blog from:
Change the two lines with the computed value objects as follows:
var dbCalendarPath='http://'+document.location.hostname+'/<Computed Value>';
and
var a='http://'+document.location.hostname+'/<Computed Value>/agnt_AJAX_Calendar?OpenAgent
(Note: the second line continues with &rdm='+Math.random() ... etc.)
Then, you must also adjust the two Computed Text Formulas: both contain an @DbLookup, which simply needs to be changed to @WebDbName (replace the entrie existing formula).

Now the Calendar sideblock reads its contents from the respective host it is opened from.
 

Comments

The fix has been implemented. But rather than using
'http://'+document.location.hostname
I have used
window.location.protocol + '//' + window.location.host
to preserve the protocol and the port (if any).

As Jens found out after I kept him busy with all this (sorry, Jens) for a bit, document.* and window.* are relative to the document executing the javascript - the to me misleading window.* doesn't refer to the window of the browser but in fact the "window" of the document (yeah, huh? ;-)) - The Gecko DOM reference (as one of many I suppose) would have provided the necessary insight, but sometimes it seems checking it out through testing just feels better :)

Hi Jens, wouldn't window.location.host fail if e.g. being previewed from google (image search)? - in other words, wouldn't document.* be more reliable for when the blog is viewed from inside a hosting frame?

 

Post a comment

 

Search

 

Calendar

Tag cloud