I can see how you can use the Acl Extension to control the push/pull to a particular repository by certian users, but can you control "WEB" access to a repository using the Acl Extenstion? I would like certain repositories to only show up for certain users.
I am deploying on IIS7, so the solution will need to work in that environment.
I'm assuming you're doing this via the HGWeb CGI script. If you are, you can specify allow_push and allow_read parameters in each project's .hg/hgrc file. If you specify an allow_read other than *, users who are not in the list will not even see the project on the HGWeb project listing page.
Just use normal .htaccess like fonctionnality to restrict which repo are accessible. hg mostly doesn't care about auth and leaves that to the web server.
Related
I'm working on a project which uses a folder full of flat-file databases. I'd like to make sure these databases are only accessible to scripts running off the server, so I set the folder permissions to 700.
This results in all scripts functioning properly, but a 403 Forbidden whenever I try to access the database folder in my browser. This is good.
However, I'm wondering: am I missing something? Is there any way — short of gaining access to my FTP account – for an outside user to access this folder? Or can I rest easy?
The proper solution is storing them outside the document root. If you cannot do that, but know that Apache will be used, create a .htaccess in the folder with the following contents:
order deny, allow
deny from all
Using filesystem permissions may or may not work depending on the environment - in a perfect setup the webserver would use the same uid as your system user that owns the files. Then your approach wouldn't work.
We're using Mercurial on our production servers for some smaller web projects to easily deploy applications by pushing changes to the server over SSH. The repositories reside in the public_html folders of their respective accounts.
Now if I do a
hg clone http://www.domain.com
I get
real URL is http://www.domain.com/
requesting all changes
adding changesets
adding manifests
transaction abort!
rollback completed
abort: empty or missing revlog for .htaccess
Fortunately, cloning doesn't seem to be possible without authentication, but I'd rather not let anyone know there is an hg repository available in the first place.
Does anybody know a way to completely hide a Mercurial repository from the public, even though it is in a public place like public_html/htdocs on webserver? I couldn't find any information on how to achieve that.
ETA: Apparently, I do not yet have enough reputation to vote any answers up. But thanks a lot to the both of you for your helpful answers. :)
In the repo's .hg/hgrc add this:
[web]
allowpull = false
That will error them out much earlier in the process, before they get any data (currently they're getting a lot of data if they want it before rollback). Note that allowpull has no underscore, unlike most other multi-word mercurial settings.
That's completely prevents them from getting the contents via mercurial, but they could still use wget, curl or a webbrowser to pick through http://www.domain.com/.hg/ manually.
To avoid that you can block any URL containing /.hg/ at the web server level. In Apache that would look like:
<Directory "/your/doc/root/.hg">
Order deny,allow
deny from all
</Directory>
You can
make the .hg directory inaccessible to your web server
make .hg invisible by .htacces magic (assuming you use an apache httpd)
place the repositories outside of public_html and populate public_html with hg archive
I have mercurial setup by following these instructions.
I'm trying to understand where or what file to setup the users in. Everything I've read seems kind of cryptic... it gives all these snippets of code saying use this but it seems to be leaving out steps of how it's all connected and what file to put the snippets of code in... can someone please de-mystify all this for the ID10T#TheKeyboard?
Keep in mind that the basic model of Mercurial cannot actually prevent anybody from checking something in. The only thing it can do is prevent those users from uploading something to the your copy of the repository.
IIS can set up authentication so that Mercurial knows which user is doing the uploading and so only certain users are even allowed to try to upload. If all you care about is limiting who has commit access to your repository you can stop right here. But if you want something finer grained, I think you are currently out of luck.
But, if it ever ends up working with web server authentication, you'll have to use the ACL extension if you want finer grained access control than simple who's allowed to send changesets to your repository.
The way the ACL extension works when changes are being sent over a network is as a pre-transaction hook on changegroups (a set of Mercurial revisions). It can look through these changegroups to make sure all the changes satisfy a given set of criteria. There are a wide variety of criteria that can be specified.
The ACL extension can be configured either in the global hgrc file, in which case it applies to all repositories, or the .hg/hgrc file of the repository you want to control access to. In my opinion the global option isn't terribly useful.
Check out the "Securing Mercurial" section here:
http://win1337ist.wordpress.com/tag/mercurial-iis7/
Also see this related question that has a lot of good info:
How to setup Mercurial and hgwebdir on IIS?
I'd like to be able to have either web dashboard logged in administrators or general users depending on which the team prefers be able to see the contents of this file without remoting into the box, is this possible using the webdashboard?
This is not an answer to how it can be seen from the web dashboard...
... but it is possible to store the ccnet.config file in source control and set up a special build on the build server that automatically retrieves the newest config file.
This way you do not even have to remote into the box in order to edit the contents of the file.
See more details in the documentation:
http://confluence.public.thoughtworks.org/display/CCNET/Configure+CruiseControl.Net+to+Automatically+Update+its+Config+File
What files should/should not be stored in the cgi-bin folder/directory on a web server?
Obviously, executable scripts/files that make up a web application, called from a web browser can be stored there.
But is there a common industry opinion about what else can be stored there?
Is there a very strong reason why nothing else apart than the scripts/executables is allowed there?
My preference is to store all files belonging to an application in the cgi-bin directory/folder, as a subfolder off it - for each application.
For example directory cgi-bin/myapplication would contain:
the cgi scripts/executables
datafiles
configuration files
This simplifies installation and also simplifies the steps to run different versions of a application in parallel, e.g. for trialling a new version.
Concerns about security access to non-script files can be addressed by using the correct user permissions and also Apache .htaccess to control access to the directory and files.
It would seem that popular free applications are in favour of this everything-under-one-directory approach: The versions of bugzilla, the free defect and feature tracking tool, e.g. 3.4.4 are offered in this structure, while earlier versions, e.g. 2.x installed bugzilla components to at least three folders.
Drupal, the powerful and popular free content management system also takes this approach of everything-under-one-directory, albeit doesn't use the cgi-bin folder but the approach is the same.
What are your thoughts?
There is nothing special about the cgi-bin folder. It is like any publicly-accessible web folder that has the "allow-script" flag set (or the equivalent for your web server) - something that has become almost meaningless in the world of PHP/JSP and the likes.
You should only store files that you wish to be public in any folder under your webroot. You probably don't want your data and configuration to be downloadable by any user on the internet, so don't keep them in /cgi-bin
Certain servers may try and execute any file in /cgi-bin if requested. This could cause problems, especially if text or data files are executed as shell script.
Applications like Drupal are intended to be easy for anyone to install, regardless of what permissions they may have on their web-host. This is the main reason it keeps everything together. If you have the ability to put files where you want, it is always a good practise to keep non-public files outside of the webroot. If you must keep them under the webroot, then ensure that you use your server's configuration to deny public access to the non-public files.