FogBugz Technical Support

A forum for technical support discussion related to Fogbugz.
The current FogBugz Knowledge Base can be found at http://help.fogcreek.com/fogbugz.

Posts by Fog Creek Employees are marked:

Documentation
Release Notes
Network Status

Separating public facing webpages from core FogBugz

Are there any plans or solutions for companies that find it insane to put something so important as bugtracking (and secret future feature descriptions!) on a public webserver?

For our internal systems I always created a webservice that exposes only a minimal interface and host the database and the "business logic" on internal servers. The only hole through the firewall into the DMZ is that webservice. This really reduces the attack surface, much more that IP-range-restrictions on single FogBugz-files like for BugScout.

Are there any plans from Fog Creek to solve this problem? Or is it very unlikely that this will ever be solved, because nowadays people are so happy to access company secrets from about any internet cafe and actually like it to be able to work on FogBugz from the next best insecure computer at any place?
(I personally trust Fog Creek to make the product very secure, BUT the best is to really reduce the attack surface)

Another solution might be that there would be an API for BugScout and discussion forms so that only this API could be opnened to the public.

The frontend for the discussion forms would then be reimplemented in other ways, maybe by ourselves or by another company or open source solution?

Just the forms and main pages of discussion groups seem not to be that hard to redo!

Monday, September 10, 2007
 
 
I'll add my vote to this one.
Per Bergland Send private email
Monday, September 10, 2007
 
 
Add my vote (multiple times in the past too)
Andrew Rowley Send private email
Monday, September 10, 2007
 
 
I would also need this!

Putting your bug database in the DMZ is ridiculous, and putting it on the internet is unbearable!

Tuesday, September 11, 2007
 
 
Will there be a reply from Fog Creek?

Wednesday, September 12, 2007
 
 
Yes there will! :)

I think you might be able to accomplish this via the api, and then only expose your api to the DMZ, but not sure how this changes anything since the api itself could still conceivably access the info.

Even if you had a crippled version of FogBugz on your public intranet, it would still have to have access to your db to show the info.  So if someone broke the security on your machine, they'd still be able to access the data.

How about creating another FogBugz installation on your public server, pointing at a db out there too, and then nightly creating a copy of your internal db out on the public machine sans the Bug table?  This would mean that the public server would be read only though.
Michael H. Pryor Send private email
Wednesday, September 12, 2007
 
 
>I think you might be able to accomplish this via the api, >and then only expose your api to the DMZ, but not sure >how this changes anything since the api itself could >still conceivably access the info.

I did not talk about exposing the existing FogBugz-API. It would have to be a securable entry-point that only exposes the minimal interace to server customers over the web.

>Even if you had a crippled version of FogBugz on your >public intranet, it would still have to have access to >your db to show the info.  So if someone broke the >security on your machine, they'd still be able to access >the data.

Exactly. Therefore the webservers never should be able to connect to internal databases. It would go through the firewall between DMZ and internal systems to the api.

>How about creating another FogBugz installation on your >public server, pointing at a db out there too, and then >nightly creating a copy of your internal db out on the >public machine sans the Bug table?  This would mean that >the public server would be read only though.

Wouldn't this have to be the other way around? Copy the discussion forms into the internal FogBugz-installation to make it possible to link discussion items to internal bugs?

Thursday, September 13, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz Bug Tracking and Evidence-Based Scheduling.