clarify difference from securesite

There is a distinct difference, it seems smart to document that indeed. Thanks again.

I still need to add a README.txt anyway.

So, what is the difference? :)

The securesite module "enables HTTP-AUTH security or an HTML form to restrict site access". Its goal is to restrict access. My goal is not to restrict access, but to "allow [registered] users to login using http authentication" if they need to.

For example, I have a school website that utilizes some node access system. Pupils and teachers all have their own user account, while visitors will be anonymous users obviously. Normally when you would subscribe to the front page RSS feed, you would only ever get to see posts that anonymous users can see. This module allows me to tell my news reader to log in with my pupil user account and get all posts that pupils can see in the feed. This is possible with the securesite module as well, but then you'd need to set a guest username and password, and are forced to use HTTP authentication, obstructing anonymous users.

So in short, securesite is focussed on securing parts of a website, httpauth is focussed on providing an alternative login method.

Tell me if my assumptions about the securesite module are completely wrong.

I totally agree with greggles on this. I haven't looked that deep into this modules functionality yet but from your description it certainly sounds like the two modules could be merged.

I also now that the maintainer of Securesite, Darren Oh, would be happy to have you on board.

I totally agree with greggles on this. I haven't looked that deep into this modules functionality yet but from your description it certainly sounds like the two modules could be merged.

I also know that the maintainer of Securesite, Darren Oh, would be happy to have you on board.

I disagree. Merging would change the whole idea of securesite, I think. It'd be de same as merging taxonomy_access and tac_lite and many of the other taxonomy modules.

I agree with naquah that the purpose of these two modules is different. HTTP Authentication allows users to authenticate with HTTP, while Secure Site prevents unauthenticated users from viewing certain pages. I also agree with greggles that there is a great deal of feature overlap. Both modules have a complete set of functions to implement HTTP authentication. Nax and chx put a lot of work into this aspect of Secure Site. I would rather contribute their work than maintain a duplicate set of features.

Merging wouldn't be that big a deal; it would just mean we make restricting page access an optional feature of Secure Site. On the other hand, it could be distributed as a related module. I'd like to discuss this further with Naquah before making a decision.

I agree with naquah that the purpose of these two modules is different. HTTP Authentication allows users to authenticate with HTTP, while Secure Site prevents unauthenticated users from viewing certain pages.

I also agree with greggles that there is a great deal of feature overlap. Both modules have a complete set of functions to implement HTTP authentication. Nax and chx put a lot of work into this aspect of Secure Site. I would rather contribute their work than maintain a duplicate set of features. Having similar features in different modules makes it harder for users to find what they want. I haven't even bothered with the different taxonomy modules, precisely because there are too many of them and I couldn't see how they were related to each other in a logical way.

Merging wouldn't be that big a deal; it would just mean we make restricting page access an optional feature of Secure Site. On the other hand, Secure Site could be trimmed down and distributed as a related module. I'd like to discuss this further with Naquah before making a decision.

I don't think a merge would be a good idea. These 2 modules both solve 2 completely different problems. Securesite is used to create private areas of a site or create an intranet/extranet site with no public areas. The httpauth module is more of authentication module, it does not stop users from seeing the site.

The only overlap between these to modules is that they use HTTP-AUTH, the difference is in the way they use HTTP-AUTH. So for me this not a feature overlap, just using the same PHP functionality.

NaX: exactly! That's what I think.

Darren Oh: I think merging into securesite would be a big deal, it would require quite some changes to that module. Any way, HTTP Authentication would be better a better name for this feature blend.

Before continuing this discussion, can someone give a real world use-case for the securesite module? (i.e. Why would I want to "protect [my] website with a browser-based password?")

I see there are good arguments for not merging the two modules :)

"Why would I want to "protect [my] website with a browser-based password?"
* Intranet type site with no public pages

Isn't Drupal perfectly capable of display a login form? Or can't Apache and/or IIS do HTTP authentication in that case? Please explain.

From the description at the poject page, my emphasizes:

"This module allows you to protect your website with a browser-based password. The usernames and passwords are tied directly to the Drupal user database. You can restrict access to the site by role. This means the site will be invisible to search engines and other crawlers, but you can still allow access to certain people."

Oh no greggles, that's where you're completely wrong. I've downloaded the module and inspected both its features and inner workings carefully. I did this before I coded httpauth, and I did it again in order to have this discussion.

I just think making the securesite module do what httpauth does, might confuse even more users because httpauth's functionality has nothing to do with securing a website. I think that even Darren Oh, the maintainer of securesite, agrees with me on that.

And I am not ruling out any kind of blend between these two modules.

@naquah, examples.
I used securesite for a company sites that ask for a public accessible site (as not no their internal network or VPN), were staff can login form anywhere and access the company intranet/extranet. On this site their are things like company news announcements, documents and a forum. They also have a public sites.

The why I personally use the securesite module is for friends. I have a few friends spread all over the globe and we were all loosing touch with each other. So after asking them if they would use it, I created a site and used the securesite module to make the site completely private. Now my friends can post pics and take part of forum discussions knowing that its all private. Their is no public side to the site as I don't have anything to show the public, its not a blog. So all the public and search engines see is a login. And that is the way my friends and family want it.

@greggles
I don't need to download securessite to see how it works because I wrote the "Bypass Login Filter Pages" feature. I had a good look at the HTTP-AUTH module and their is a fundamental difference in how it works compared to the secures site module, but since you asked I will have a better look later tonight.

From what I can tell (correct me if I am wrong) the HTTP-AUTH module is only for access denied pages and specified pages like RSS feeds.

@greggles: Have you downloaded httpauth?

@NaX:

About the example: that only seems like an alternative to removing the access content permission for the anonymous user role, which will effectively make your site private because Drupal will only show a login block on the front page, right? Granted, it is a more streamlined way to secure your site. (Which is exactly what httpauth is not for, indeed.)

About your last assumption: effectively, yes. It will accept credentials on any page, but it will actually ask the browser if either an access denied exception is thrown on specified pages (I only want to force HTTP authentication if access denied is shown for an RSS feed, not for a node, for example) or if authenticate is found in the query string. Really the ultimate purpose for httpauth is being able to read RSS feeds that either require authentication or contain more content if you're authenticated (because of some node access system) in a news reader.

Oh yes, and I'm looking into Digest HTTP authentication, since it might allow multiple authentication realms on one domain. That might even allow httpauth and securesite to work side-by-side! (However, I'm not sure about that.)

I appreciate the thought that is going into this discussion. From a user's point of view, mixing unrelated features is as bad as feature overlap. And I am looking at this from a user's perspective. I don't understand the details of Secure Site as NaX does. I took over the project to make the work of NaX and other developers available to all Drupal users.

NaX and naquah, what I am wondering is this: could our efforts be harnessed more effectively in the future if we limit Secure Site to controlling which parts of the site unauthenticated users have access to and leave the actual authentication to other modules?

Naquah, I used Secure Site when I was developing a site that I didn't want to appear in search engine results until it was finished.

@21: Thanks for contributing to this discussion. About your question: do you mean in the sense of sharing a common HTTP authentication backend, or httpauth being this backend? Most certainly a good idea, then we'd have to figure out what level of abstraction the backend/api should have, i.e. what functions it should expose in order to be usable by other modules.

@22: For that purpose I would secure the site by adding some allow/deny stuff in .htaccess, but good example any way, especially in a case where you can't use .htaccess.

I like the idea of an http-auth library. It wont be a very big library of functions unless we explore things like Digest authentication.

I think a library/API would be far better than merging the modules.

I have to agree that the apparent feature overlap is confusing and a problem for contributed modules. Here is what I wish to do.

I want to password protect drupal podcasts (rss feeds with files attached (enclosures)) and the enclosures themselves (files in the /files location). Then when you subscribe to the feed in iTunes it will prompt you for a username and password (assuming Drupal returns the 403) and will then start the HTTP authentication process. iTunes uses digest authentication.

Which of these two modules is the right choice for implementing this or the at least the right starting point to add this.

Thanks for the hard work on both modules.

my bad - sorry.

I think you should try out the httpauth module. If you enable the module and set the desired paths, the client (iTunes in this case) will be asked to authenticate if Drupal returns the 403 status.

This module only supports Basic authentication for now, Digest is a planned feature. But a quick search proves that iTunes will support Basic as well as Digest authentication.

naquah,

Thanks - I grabbed the module for cvs and tried it out with mixed success. I added the module and configured it to promote auth on

blog/*
system/files/*

I get the expected auth prompt when I try to go to say blog/1/feed from the browser and I could also get the feed with wget with the proper username and password and 401 when sending no username or password. I could not get this to work with iTunes so either basic auth is not working there or there is another problem. I'm trying to figure that out now.

Also, I had my site set up for that anonymous role has no access at all including content. With this set I was unable to log out of my site with httpauth turned on - any ideas?

When would you hope/like to have digest mode and what are your plans for 5.0 support?

Thank you very much for your feedback!

Can you please create a new issue for the authentication not working with iTunes? State what modules you're using exactly for the enclosures (I'm not really into podcasts using Drupal) so I will be able to test it myself and try to fix the problem.

The problem of not being able to logout is a known issue (http://drupal.org/node/97931).

I am using this module myself in a production site as well, so I will need a 5.0 version as well!

I think I will have the logout issue fixed, Digest authentication implemented and a 5.0 version ready before the end of this year.

I've tried to find out whether httpauth and/or securesite can make use of mod_auth_pam-based authentication but to no avail. I'm starting to suspect they can't but would be happy to be proven wrong. Can you tell whether my assumption is correct, please? And if yes, would it be hard to create such a drupal module e.g. using httpauth as a starting point?

P.S: I'm running Apache2 (2.0.55) + Drupal 5.1 + PHP 5.1.6 on an Ubuntu 6.10 box and configured to use mod_auth_pam for user authentication.

@miguelinho: you would need a very different module to do that, I think. Note that authentication module is a bit ambiguous since it can do two things: allow a user to login in a specific way (like httpauth), or allow a user to login using a username and password from a source other than Drupal (like Drupal's distributed authentication). You need the latter: a module that will tell Drupal to accept usernames and passwords that are in passwd. How this would be integrated with an Apache module like mod_auth_pam, I'm not sure.

Hi, so here I am, your confused user.

I wrote about it at http://drupal.org/node/233895 but it seems there are not many people who can help me. I'm still looking for a tutorial, but httpauth hasn't even got a readme file. I'm not quite capable of analysing the source code, so could someone tell me where to find the info to solve my problem?

Pretty Please!

The HTTP authentication will be deprecated in favour of Secure Site.