I'm having trouble with webfm in a fresh 5.1 installation. The only other modules active are related to views (I've tried disabling all others to no avail). The /admin/webfm page shows me a "working" status that never goes away, and my attempts to "refresh" the file list result in a "current directory undefined" debug error.

The requisite directories are created and configured (I think) correctly, with permissions set so the web server has write access. I've added temporary files that don't show up.

The attached image shows what I'm talking about.

Am I missing something obvious? Or perhaps something not so obvious?

Thanks.

CommentFileSizeAuthor
ds-webfm-2.png51.19 KBghoti

Comments

robmilne’s picture

robmilne commented

You may need to flush the menu cache to create the ajax path back to the server. Try navigating to /admin/build/menu and see if that corrects the problem.

robmilne’s picture

robmilne commented

I just realised that there was an attached image. Looks like the path to the icons isn't set properly. This is a bug that has been corrected in the dev release.

ghoti’s picture

ghoti commented

Thanks for the quick response.

I've downloaded the latest from CVS, and it exhibits identical behaviour.

I suspect the missing icon path is a symptom, not the problem; the Debug output indicates another path issue whenever I "refresh".

I was thinking I'd wander through js/webfm.js and replace "blue" in every Webfm.progressObj.show(Webfm.js_msg["work"], "blue"); with a different colour, to nail down which one is failing to clear.

ghoti’s picture

ghoti commented

Okay, here's something. I suspect that the icons are missing because of how this site is being served. The web server runs HTTP, but is visible to the outside (including me) via HTTPS through a reverse proxy. So applications *can* look at HTTP headers to determine whether SSL is on, but in general we're relying on relative URLs for stuff.

This probably means that for icons to show up, I'll need an option that lets me "force" the URL prefix, since in this scenario, the existence of SSL may be hidden.

For what it's worth, I'm using Pound from http://www.apsis.ch/pound as the proxy.

This probably explains the rest of the AJAX failures as well. If everything thinks we're HTTP, then the handler will never be hit.

ghoti’s picture

ghoti commented
Title: "current directory undefined" ? » HTTP Proxy unfriendly

Sure enough -- I just created an HTTP proxy to go along with the HTTPS one, and webfm works like a charm.

To be clear, this is the setup that confuses webfm:

user --(HTTPS)--> proxy --(HTTP)--> apache

It seems to me that we need a way to override getBaseUrl() as used by Webfm.ajaxUrl (webfm.js line 2381), or a way to teach it to respect the additional header lines added by the proxy (since $_SERVER["HTTP_X_FORWARDED_PROTO"]=="https"). I haven't figured out how to do this yet; if you know, please tell me to stop looking. :)

p

robmilne’s picture

robmilne commented

You are in uncharted waters for me so I have no suggestions to offer. Please keep me posted with your findings since this issue is likely to repeat.

Btw, it is already possible to override Webfm.ajaxUrl with the getModUrl() method. This function simply returns a user defined ajax path to the server. A typical instantiation can be found in the inline js code of webfm_ext_example.module.remove.

ghoti’s picture

ghoti commented

Hrm. Your modesty is unwarranted. :-)

My JS-foo is not so great, so my quick workaround was to replace getBaseUrl() in webfm.js line 2381 with "https://my.dom.ain/". :-)

After some research, it appears that your JS getBaseUrl() relies on $base_url, which is a global. So I suspect the "proper" fix should be to patch Drupal's own includes/bootstrap.inc around line 252 with stuff to recognize reverse-proxy spoor and set $base_url correctly. I'll submit a patch and see what happens.

Thanks for your help.

akeimou’s picture

akeimou commented

i had a similar problem. http://drupal.org/node/150800#comment-1113306. thanks to ghoti for the quick workaround. has a "proper" fix been submitted on a related issue perhaps?

robmilne’s picture

robmilne commented

I have never worked with proxy servers but a recent fix in node 310119 for pasting links into content may provide a solution. The javascript calls to getBaseUrl() can be replaced with the alternative call to getBasePath(). I've replaced the instances of getBaseUrl() with getBasePath().replace(/\/$/,'') at line 1218, 1703, 2027 and 3747 in webfm.js (RC3) and it runs fine on both my localhost and external server. I invite you to try this for your proxy setup and see if it resolves the issue.

akeimou’s picture

akeimou commented

ah, indeed, both http://localhost/path/webfm and https://localhost/path/webfm work fine while on the external server, https://my.domain/webfm works fine but not http://my.domain/webfm with the "server is unreachable" error. i just realized that https://my.domain/webfm has been working all along and that what replacing getBaseUrl() with https://my.domain/ does is to avoid http://my.domain/ altogether.

i've tried the latest suggestion with getBasePath() and it didn't change anything.

me neither, i've never worked with proxy servers, i don't even know where/how to start figuring out why a straight copy of an external drupal site to a subarea in localhost, gets webfm working on both http and https!

(except of course for difference in settings.php, software versions and configurations)

so i think what's best for me right now is to use a RewriteRule in the VirtualHost definition for my.domain:80 to redirect http://my.domain/webfm to https://my.domain/webfm (even if we want SSL only on login). haven't tried it yet.

ghoti’s picture

ghoti commented

Just because this is still open, I'll post something to it. :)

http://drupal.org/node/313145 contains a patch that fixes the $base_url problem in includes/bootstrap.inc. The patch works, even though it fails some error handling test -- I'm using it (or a D6 version) in production on all my Drupal sites.

I haven't tested this with webfm yet though.

And I haven't had time to set up a proper Drupal test environment to get details on why the patch fails the automatic tests. If someone else has a test environment handy, that would be *great*.

nhck’s picture

nhck commented
Status: Active » Closed (won't fix)

As per #803722: Cease support of Drupal 5? support for D4 and D5 has been closed. Sorry, please upgrade to Drupal 6. If you think this issue still applies with Version 6.x please reopen this issue with correct version tag.

Thank you! :-)