FogBugz Technical Support

A forum for technical support discussion related to Fogbugz.
The current FogBugz Knowledge Base can be found at

Posts by Fog Creek Employees are marked:

Release Notes
Network Status

Password protect FB Forums?

We have FB 5 hosted on a public server so folks outside the company can use it. I'd like to use the forums for technical and strategic discussions, but don't want that stuff public.

Is there any way to limit access to those forums?
Aphasia Software Send private email
Saturday, December 30, 2006
No, there is no way to limit use of the forums.

Unfortunately, there are only two ways to use the FB forums (based on a couple of years of personal experience):

a) Only allow your core team to log in to FogBugz so you can discuss deep technical things on the Fogbugz forums


b) Don't use the Fogbugz forums at all.

Unfortunately for us, back when we first rolled out Fogbugz v4, we started using the forums and turned off our old 'developer only' NNTP server. We set up our web dev, QA, and tech support folks as users in our FB system.

Then we discovered 'hey, those web dev, QA and tech support folks can see all these really private internal discussions on the fog bugz discussion groups! Ack!'

We ended up throwing out all the web dev, QA and tech support users. So only our core team uses fogbugz.

NOT what we wanted (or what we paid for, as those extra seats are just sitting unused).

This issue has come up many times here on the Fog Creek forums.  Here are a few mentions.
Sam Jones Send private email
Monday, January 1, 2007

You have two options for limiting access to the forums.  You can either add the users to fogbugz and then make the discussion group private, or make the discussion groups public, but add HTTP Authentication to your fogbugz site.  That way the people you want to see the forums will be able to with the password you give them, and random public people will not, but they won't require FogBugz logins.  Hope that helps!
Michael H. Pryor Send private email
Monday, January 1, 2007
HTTP authentication would be nice to set up. The problem is that as far as I can tell we need to reverse engineer the URLs and parameters to work out exactly what to secure.

Any chance of producing some documentation on exactly which URLs can be used to access particular functions of Fogbugz?
Andrew Rowley Send private email
Tuesday, January 2, 2007
Actually every FogBugz url is default.asp.  But what I'm saying is you can have two levels of authentication.  The first is HTTP which keeps your site semi-private in that you can make a PUBLIC discussion forum, but the members will still need to know your http authentication password.  Then there is the super secure level which is they need an account to log in to FogBugz.  So basically you would give everyone outside your company the semi-secure HTTP authentication to keep the public from viewing those pages.

If you need different passwords for different discussion forums, the urls look like this
Michael H. Pryor Send private email
Wednesday, January 3, 2007
"If you need different passwords for different discussion forums, the urls look like this"

Except the ones that look like
maybe others?

What I was hoping to do was to use something like ModSecurity to make the discussion group area of the site public, but stop anyone on an external network from being able to access other pages. I looked into it, but there didn't seem to be any consistency in what to check.

You could do people a big favor by reworking things so that it is possible to secure various functions at the http server level. At the moment it is not really possible.

This should also make it easier to do things like password protecting individual forums or functions.

To me, needing an account to log on to FogBugz is not "super secure". It's probably OK for most sites, but there are a couple of things that are needed to consider it secure:
- userids that are not easily guessable (ie. not full name or email address)
- logging and notification of failed logon attempts
- some sort of mecanism to stop brute force password guessing - revoke the id for a period of time etc.
- security at the database level, so that data is protected even if Fogbugz makes an error in checking the authentication.
Andrew Rowley Send private email
Wednesday, January 3, 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.