114344 - Using bugzilla via ssh port forwarding as well as on an internal LAN

Status: NEW

(Bugzilla :: Bugzilla-General, enhancement, P4)

Description

[Svein E. Seldal]

I am using bugzilla on a RH 7.1 behind a firewall system. The webserver that 
runs a local (apache) webserver on port 81. This webserver on 81 should and 
will never be directly accessible from the internet. Bugzilla is installed on 
port 81. I had to install my own webdot (also on 81) because no external webdot 
server could reach my server. I had to change data/webdot/.htaccess - no big 
news - to be able to use webdot from local machine (Change 1).

Now, most of our users, the means of accessing the bugzilla server from the 
internet, is via. SSH portforwaring:

This means that there is two distinct ways of accessing bugzilla:
via SSH:      http://127.0.0.1:81/bugs/index.html
or localnet:  http://bugs.foo.bar:81/bugs/index.html

This required me to be able to use a relative urlbase (/bugs/). I had to modify 
defparms.pl (Change 2) to be able to accept relative addresses.

When this change was done, the dependency-printing (the webdot's images) 
created faulty links because of the relative addressing. I changed 
showdependencygraph.cgi to create .dot files with absolute addressing (change 
3). But since our users can both come from localhost (SSH) or from the 
localnet, this had to be read from the environmentvariable HTTP_HOST.

I would like you to consider looking at the attached patch and implement these 
changes. The patch looks more like a hack today, but I was hoping you would 
implement this is a cleaner way. This will benefit those which are using a 
bugzilla in a private and local network.

Comment 1

[Svein E. Seldal]

Attachment: A patch with the changes described in the description

This is the changes to bugzilla that works for me. This is uncomplete for a
production system, but it outlines what have to be done get it to work.

Comment 2

[Dave Miller [:justdave]]

Question: what does the url look like in the emails?  That would be my main
concern.  The pages themselves could probably figure out their own urlbase by
using HTTP_HOST and SCRIPT_NAME.  The primary use for urlbase where this
wouldn't be feasable is from generated emails and from reports mailed from cron
jobs (i.e. whineatnews.pl)

Comment 3

[Svein E. Seldal]

I just discovered that it prints the mail-links using the relative address 
(only) - this is of course unacceptable.

IMHO the best solution to this is probably to extract the relative part of the 
urlbase - like Param('relurlbase'), and use this from all CGI-based script. For 
the non-cgi scripts, they can use the 'urlbase' parameter as usual.  ((Maybe 
its better the other way around; all uses 'urlbase' as of today, and the non-
cgi scripts uses 'absurlbase' or something?))

Comment 4

[Dave Miller [:justdave]]

I seem to recall some spots in the CGI generated pages specifically being
changed to use the absolute URL for some reason...

I think it was the bug links on buglist.cgi.  The theory being if you saved a
buglist as a local HTML file, the links would still work to pull up the relevant
bugs...

Comment 5

[Svein E. Seldal]

True. If relative addressing were implemented, it could be up to the person 
configuring bugzilla to decide: If he uses the http:// prefix in urlbase, the 
users can save the list and use it from elsewhere (e.g. locally). If he uses 
relative addressing, well, the users cannot use it from other places than the 
machine generating it.

A solution could be like this: The dynamic HTML pages that is generated uses 
HTTP_HOST actively in all links and references. This would in the SSH case, 
create links with "http://127.0.0.1:81" prefixes. The user would then be able 
to save it and use it locally (given that the SSH link is established in 
advance). The real absoulute name for the bugzilla server is useless for the 
users connecting from SSH anyway, and this enhancement would certainly fix it 
for them.

Anyway, I'm running relative addresses now, and I will sure see if anything 
queer shows up.

Comment 6

[Bradley Baetz (:bbaetz)]

Comment on attachment 61040 [details] [diff] [review]
A patch with the changes described in the description

This needs-work per comments (also, the patch is garbage - what format is it?)

We use absolute urls when we want them to, eg for saving/forwarding to someone
else/etc. In other words, I'm not sure that this is useful..

Comment 7

[Joel Peshkin]

Unloved bugs targetted for 2.18 but untouched since 9-15-2003 are being
retargeted to 2.20
If you plan to act on one immediately, go ahead and pull it back to 2.18.

Comment 8

[Dave Miller [:justdave]]

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.

Comment 9

[Dave Miller [:justdave]]

Reassigning bugs that I'm not actively working on to the default component owner
in order to try to make some sanity out of my personal buglist.  This doesn't
mean the bug isn't being dealt with, just that I'm not the one doing it.  If you
are dealing with this bug, please assign it to yourself.

Comment 10

[justin foutts]

BUGZILLA CANNOT BE USED BY CUSTOMER.

changing priority: BLOCKER

This is an old bug guys, move it out of enhancements.  We need relative url basing now, the current situation is ridiculous.

Comment 11

[Daniel Franke]

bugzilla-2.22:
As described in the original post from 2001, I tried to tunnel a connection to or internal bugzilla server:
$> ssh -N [e-mail] -L 8080:internalhost.somedomain.com:80

When pointing a browser to http://localhost:8080, the login page is displayed. Entering the credentials and "Login" changes the browser address from http://localhost:8080 to http://internalhost.somedomain.com/bugzilla/index.cgi - which does not work for obvious reasons.

Is this an all-or-nothing, i.e. make bugzilla globally accessible or not at all?

Comment 12

[Tomasz Jaszowski]

point internalhost.somedomain.com to localhost/end_tunnel_host in your /etc/hosts and it will work - I know, it's workaround... but works perfectly for me

Comment 13

[Andris Pavenis]

One could perhaps add something like

my $localurlbase = $urlbase;
$localurlbase =~ s@^[^:]+://[^/]+@@;

And use $localurlbase in URLs where needed, but not sent e-mails as otherwise 
sent e-mails would show wrong URL for local users.

It is however impossible to get sent e-mails right for both local and remote users. As result RRLS in for example and e-mail sent about change related to some bug cannot work for both local users and remote users through SSH tunnel.

So I guess things will remain broken even if host part will be removed from $urlbase in all or part of places where it is used.

Other way without modifications of Bugzilla code is to access Bugzilla through reverse proxy. I myself have not very much experience in configuring Apache so I did not succeed to get it working (I did not have very much time for it either). Reverse proxy must also rewrite URLS in Javascript so pattern based rules must be used.

Even in that case URLs in e-mails sent by Bugzilla will be wrong for either accessing Bugzilla directly or through reverse proxy.

As result I don't see another way rather than hack suggested by Tomasz Jaszowski before, if one wants for as less as possible things to be broken.

Comment 14

[Vitaly Fedrushkov]

See also bug 399069 comment 9