Please upgrade here. These earlier versions are no longer being updated and have security issues.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Server-relative vs page-relative

edited May 2011 in Vanilla 2.0 - 2.8
I've been mucking around with a Vanilla_2.0.17.10 installation inside my workplace local network. We're behind a proxy, and requests are bumped around several servers until they reach the ones I have direct control over.

The forum works fine inside the local network, however outside it css and js files are not read...

<link media="screen" href="/forum-folder/applications/dashboard/design/style.css?v=2.0.17.10" type="text/css" rel="stylesheet">

the problem seems that the server-relative links, that are written (such as above) aren't read. My guess is that it has something to do with my server being buried deep within the network and/or my lack of knowledge over proper server admin. (after a couple of hours with the local sys-admin the problem remained unsolved :( )

However, when using firebug, if I change the above link to it's page-relative version

<link media="screen" href="applications/dashboard/design/style.css?v=2.0.17.10" type="text/css" rel="stylesheet">

CSS loads fine. So my question is, I would go about making vanilla write page-relative links instead of the server-relative?

Comments

  • So what do you get if you attempt to access the file directly, i.e.

    http://www.example.com/forum-folder/applications/dashboard/design/style.css

    ? Rather than guessing that the browser cannot access it, let's take a step into what the browser is requesting.
  • Hi judgej,

    Thanks for the reply :)

    I can actually access the css file, if I manually prefix the page-relative css link with the base link used to access the forum from the outside.

    However I have no (working) idea how to make the server (or vanilla) either do this automatic prefixing, or the truncation I've asked about above. :(

    ~K
  • Do you have different base paths for internal and external use? For example, do you have:

    http://internal.example.com/my-internal-path-to-my-forum/

    and

    http://external.example.com/a-different-external-path-to-my-forum/

    Or perhaps you have a path externally, but not internally? You are going to have to give us more information about what these URLs are, and how they differ between your local and external networks, otherwise we are just guessing what is going on.
  • Internally the paths just go by the http://server.ip.address/forum-folder/


    Externally, I just can access it using the domain name
    for instance, to access the test instance of the previously mentioned css file I would use:
    http://xldb.di.fc.ul.pt/tools/dev/biox-forum/applications/dashboard/design/style.css?v=2.0.17.10
  • It looks like you need to rewrite "/forum-folder" to "/tools/dev/biox-forum" on the external server. That would be the easy way to handle it (so long as "forum-folder" is not giving anything away with a security implication). However, I suspect that you may not have access to the part of the site where that would need to be set up.
  • judgejjudgej
    edited May 2011
    Maybe a better way would be to fool Vanilla into believing it is on one path or another, depending on where it is being accessed from. I have a hunch it would be done via this parameter:

    $Configuration['Garden']['WebRoot']

    This is normally set in the config file, but could probably be reset in the bootstrap file with a check of where the user is accessing from (local IP, or forwarded by a proxy, for example).

    Sorry if this all sounds like black magic - I'm hoping someone else with experience in this kind of thing will jump in here ;-)

    If you can, as an experiment, by setting the webroot value in the main config file, and see if it starts working externally (it will probably break internal access):

    $Configuration['Garden']['WebRoot'] = '/tools/dev/biox-forum/';

    or even:

    $Configuration['Garden']['WebRoot'] = 'http://xldb.di.fc.ul.pt/tools/dev/biox-forum/';

    If that works, then we are a step forward.
  • A final approach may be to set it up to work externally, then tell everyone to access it using the external domain *only*.
  • Well, I personally don't have access on the topmost/external/gateway server.

    What I know is:

    there's n-servers and somewhere along the line requests for the sub-domain 'xldb' are sent our way, to a server which although "I know" I also don't have access.

    But at that level, requests for xldb.di.fc.ul.pt/tools/ are sent to the first topmost server I have control over. So, finally, at that server I've currently defined a
    ProxyPass /tools/dev/biox-forum/ ...final-internal-server/biox-forum/
    and probably a lame attempt to solve my problems with a
    ProxyPassReverse / ...final-internal-server/biox-forum/
    too

    I've gave a whirl messing with $Configuration['Garden']['WebRoot']
    but had no luck... regardless using your insights I'll keep trying...

    What do you mean by setting it externally? the whole server? make it public?
  • Well, I manage to figure out (confirm) the root problem. It was as suspected a network/server configuration problem. The server-relative requests where being made to the server that is the 1st recipient for all the requests of said sub-domain, and not the server that hosted the forum. I just add to nudge the admin to let me access and edit the respective httpd.conf in order to allow to capture those requests and send them to my hosting server. :)

    Then I just had to fiddle with changing ownership of the forum files to apache, re-writes on the configs.php to FALSE and so far everything seems fine (except a little fussy little re-direct logout issue, which I think I've already seen some thread complain about that too).

    That said, I've also stumbled upon some others threads that stated that
    $Configuration['Garden']['WebRoot']

    is no longer used, which if it works as we intended/expected is a pity, because it could perhaps solve problems in cases where admin were more stringent than mine.

    Thanks again judgej for the insights :)

    ~K
Sign In or Register to comment.