Mapstraction - Nov 2010 - Mapstraction not working behind company firewall/load balancers: First solution

Hi allI had a huge problem that my maps based on mapstraction/Google worked
wonderful, but they did suddenly not work when collegues watched the maps with
browsers behind our company firewall or load balancers. I found the problem,
which I present here, together with a first workaround. I think others can have
the same problem and did perhaps not yet find the problem.The problem was that
our company firewall does insert code (!) into all javascript commands which
have a script tag.It does for example make from:<script
type="text/javascript"
src="../../res/js/map.js"></script>
the following:<script type="text/javascript"
src="../../res/js/map.js?sfgdata=+sfgRmluamFuX1R5cGU9amF2YV9zY3JpcHQmRmluamFuX0xhbmc9dGV4dC9qYXZhc2NyaXB0+q"></script>
Normally this is not a problem for the browsers, it is ignored. But in the case
of Mapstraction there is a problem with the parametrized initialisation of
mxn:From <script type="text/javascript" charset="utf-8"
src="http://mapstraction.googlecode.com/svn/trunk/source/mxn.js?(google)"></script>
the firewall does make (all on one line):<script
type="text/javascript" charset="utf-8"
src="http://mapstraction.googlecode.com/svn/trunk/source/mxn.js?(google)&amp;sfgdata=+sfgRmluamFuX1R5cGU9amF2YV9zY3JpcHQmRmluamFuX0xhbmc9dGV4dC9qYXZhc2NyaXB0+a"></script>
The code inside mxn reading the parameters ("?(google)") is
unfortunately too strict and does after the insertion not recognize any
parameters anymore. The result is that the google initialisiation script is not
executed and users face a black map on their screen.My workaround is now not to
use this kind of simple initialisation, but to initalize google explicit.
Instead of:<script type="text/javascript" charset="utf-8"
src="http://mapstraction.googlecode.com/svn/trunk/source/mxn.js?(google)"></script>
I have now:<script type="text/javascript"
src="http://mapstraction.googlecode.com/svn/trunk/source/mxn.js"></script>
<script type="text/javascript"
src="http://mapstraction.googlecode.com/svn/trunk/source/mxn.core.js"></script>
<script type="text/javascript"
src="http://mapstraction.googlecode.com/svn/trunk/source/mxn.google.core.js"></script>
this works also behind my company firewall or load balancers.

Another solution would be to slightly adapt the argument parser inside mxn. It
is the line:var match = scripts[i].src.replace(/%20/g ,
'''').match(/^(.*?)mxn\.js(\?\(\[?(.*?)\]?\))?$/);
The line does expect a format till end of the line. This way the inserted code
does breakup the analysis for parameters. If others do have the same problem
with maps behind their company firewalls or load balancers I recommend to fix it
on this line for all. A quick search in google for "sfgdata" showed me
that others experienced behind firewalls or loadbalancers similar inserted code.
Mapstraction should ignore it, not getting killed by this.Ernst
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20101109/758eaa36/attachment.htm>

Hi Ernst,

nice bug, nice solution.

Why not check out mxn from github and submit the patch yourself?
https://github.com/mapstraction/mxn

best,
Ed


2010/11/9 ernst.versteeg300 at bluewin.ch <ernst.versteeg300 at
bluewin.ch>:
> Hi all
>
> I had a huge problem that my maps based on mapstraction/Google worked
> wonderful, but they did suddenly not work when collegues watched the maps
> with browsers behind our company firewall or load balancers. I found the
> problem, which I present here, together with a first workaround. I think
> others can have the same problem and did perhaps not yet find the problem.
>
> The problem was that our company firewall does insert code (!) into all
> javascript commands which have a script tag.
>
> It does for example make from:
>
> <script type="text/javascript"
src="../../res/js/map.js"></script>
>
> the following:
>
> <script type="text/javascript"
>
src="../../res/js/map.js?sfgdata=+sfgRmluamFuX1R5cGU9amF2YV9zY3JpcHQmRmluamFuX0xhbmc9dGV4dC9qYXZhc2NyaXB0+q"></script>
>
> Normally this is not a problem for the browsers, it is ignored. But in the
> case of Mapstraction there is a problem with the parametrized
initialisation
> of mxn:
>
> From
>
> <script type="text/javascript" charset="utf-8"
>
src="http://mapstraction.googlecode.com/svn/trunk/source/mxn.js?(google)"></script>
>
> the firewall does make (all on one line):
>
> <script type="text/javascript" charset="utf-8"
>
src="http://mapstraction.googlecode.com/svn/trunk/source/mxn.js?(google)&sfgdata=+sfgRmluamFuX1R5cGU9amF2YV9zY3JpcHQmRmluamFuX0xhbmc9dGV4dC9qYXZhc2NyaXB0+a"></script>
>
> The code inside mxn reading the parameters ("?(google)") is
unfortunately
> too strict and does after the insertion not recognize any parameters
> anymore. The result is that the google initialisiation script is not
> executed and users face a black map on their screen.
>
> My workaround is now not to use this kind of simple initialisation, but to
> initalize google explicit.
>
> Instead of:
>
> <script type="text/javascript" charset="utf-8"
>
src="http://mapstraction.googlecode.com/svn/trunk/source/mxn.js?(google)"></script>
>
> I have now:
>
> <script type="text/javascript"
>
src="http://mapstraction.googlecode.com/svn/trunk/source/mxn.js"></script>
> <script type="text/javascript"
>
src="http://mapstraction.googlecode.com/svn/trunk/source/mxn.core.js"></script>
> <script type="text/javascript"
>
src="http://mapstraction.googlecode.com/svn/trunk/source/mxn.google.core.js"></script>
>
> this works also behind my company firewall or load balancers.
>
> Another solution would be to slightly adapt the argument parser inside mxn.
> It is the line:
>
> var match = scripts[i].src.replace(/%20/g ,
> '''').match(/^(.*?)mxn\.js(\?\(\[?(.*?)\]?\))?$/);
>
> The line does expect a format till end of the line. This way the inserted
> code does breakup the analysis for parameters. If others do have the same
> problem with maps behind their company firewalls or load balancers I
> recommend to fix it on this line for all. A quick search in google for
> "sfgdata" showed me that others experienced behind firewalls or
> loadbalancers similar inserted code. Mapstraction should ignore it, not
> getting killed by this.
>
> Ernst
>
>
>
> _______________________________________________
> Mapstraction mailing list
> Mapstraction at lists.mapstraction.com
> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>
>