Camen Design Forum

Your ideas, suggestions for an NNF access-limitation feature (HTTP_AUTH)

append delete Kroc

Hello all. Some design questions have arison as part of a planned feature for NoNonsense Forum and I wanted everybody’s input.

--- here comes the science bit! ---

Basically, there would seem a need (not sure how widespread this is) to be able to run a private NoNonsense Forum that only certain people could access / post to.

Initially I was looking at using ".htpasswd", an Apache method that prompts the browser for login and authenticates against a given list of users. This essentially means that I don’t have to code a login screen, the browser provides it for you.

Use of .htpasswd is flawed however because:

a) The user needs to edit their ".htaccess" file, making it harder to update to new versions
b) The path to the ".htpasswd" file has to be absolute, which is hard to know on shared hosting and less friendly to newbies
c) It effectively by-passes the already existing name/password system, relying on the ".htpasswd" file instead. This is more of an internal design conflict, but does raise questions as to the worth of adding the feature

I can add HTTP authorisation using PHP (no need for htpasswd), but then you could just enter any name and password because the normal behaviour is to create a user if they don’t exist; so what gain would there be from an HTTP_AUTH request, rather than the name/password boxes that already exist?

There would need to be another feature (a text file likely) to say that only users x, y & z can view the forum.

This poses a UI problem; what do you make visible and accessible, and what do you not? These are more features to consider. Do you make the forum visible to all, but only accept submits from allowed usernames (bad UI), or do you provide a "login" button that invokes the authorisation request and only then display the input forms? Do you hide the entire forum and don’t allow them to see anything untill they’ve logged in? (then search won't work anymore because it relies on Google). Should the forum display a splash screen and require them to click to log in rather than just throwing an auth request at them the second they visit the URL?

This whole thing seems like a slippery slope that conflicts with the design of NNF and will only lead to conflicting feature requests (like alternative serch code for private forums).

What are your thoughts on NNF having a "only allow specific users" feature, and how it would be implemented?

Reply RSS

Replies

append delete #1. Ben

When I first installed NNF it was for committee discussions and we blocked access to the Committee folder with .htpasswd. I found it very easy to manage. People could see the last poster and the date of posting, but no more than that.

I think that any other system would be more complicated for end-users. Complications for the site manager is fine, since if they can't understand the feature then they are likely to not really miss its use (and could go elsewhere for a forum script that suited their needs).

append delete #2. theraje

Hmm... could you do something akin to the mod-tools already implemented?

For each private forum, you could have a special members .txt file. When entering any special-permissions forum, the user is prompted to enter his name/pass combo, and if the data matches an entry in the txt members file for that forum, they will be allowed to view the forum.

As an alternative, you could do the members text file, but instead of having to "login" to enter the forum, you can enter the forum, but viewing a topic's contents would require posting user credentials.

Either method would require users to post their member info much more often... but I suppose it's the only way to work it out with the way things are for NNF.

Also, isn't there a way to disable new-user signups? (There is IIRC, but I couldn't swear to it. Just an idea that forums could be individually configured to disallow new user signups, and posts not entered by an actual user would be rejected.)

append delete #3. Jose Pedro Arvela

A read-only forum and a private forum serve two different purposes, and the possibilities of each should be considered independently.

Regarding interfaces, here is how I think a private and a read-only forum could be shown to the user:

A private forum could simply have the login form beneath the title (which should no longer link to the forum itself). This way the user knows that only by entering the proper username and password combination beforehand can they enter the forum. Here's a mockup:

https://lh4.googleusercontent.com/-Z2MV6U1exNg/TtGGBKMOXEI/AAAAAAAAAQs/u26F_Wqhrjs/s800/Kroc%252520Mockup.png

I suggest this because, unfortunately, browsers still haven't improved their own HTTP Auth based login form. Any person used to browsing using multiple tabs would deal badly with this as the login windows opened are usually window modal instead of tab modal in most browsers. If a person opens many tabs at once and, for some reason, the connection is slow enough the user has time to move to another tab after clicking the link (happened to me before), they will be granted a possibly confusing message they do not know how to handle due to the lack of tab context. Unfortunately this browser shortcoming is something we have to deal with.

Regarding read-only forums, I think a good idea would be to use CSS to dim the comment form and show a warning message until both the username and password are filled. As shown in the following image:

https://lh3.googleusercontent.com/-0txP-HpnPmU/TtGGBEGx0eI/AAAAAAAAAQw/PtqrASkHoEc/s800/Kroc%252520Mockup%2525202.png 

% Example CSS (this was not tested)
#warning {
display: none;
position: absolute; top: 0; bottom: 0; left: 0; width: 65%;
}
#user[value=""] ~ #warning, #pass[value=""] ~ #warning {
display: block;
}
%

Private forums would certainly always have the same shortcoming of lacking Google search, as even implementing it would be a privacy breach. The closest way I can imagine of bypassing this would be an option to show all threads in the same page, and then use Ctrl+F to find content on a title. If this is to be implemented, it will either be with a custom search or no search at all. Nonetheless, I do think a private forum is worth, even if without search.

If .htpasswd is used, then the simplest idea for read only forums would be to have a big "Comment" button in the middle, which would lead to the HTTP authentication, as shown here:

https://lh4.googleusercontent.com/-mBoVMwbGz7I/TtGMxLHSJOI/AAAAAAAAARc/aQI8kFuEZ0U/s800/Kroc%252520Mockup%2525204.png

It then would show a form with a comment form available with the username field filled and disabled (with a link to change the username being used below it instead of a password field).

https://lh3.googleusercontent.com/-QyNnrVsQNkE/TtGL0TZ8bqI/AAAAAAAAARM/BBu-s7pR58w/s800/Kroc%252520Mockup%2525203.png

It does involve more clicks, but it seems to me an intuitive way of guiding the user (I can still imagine tough "Where is the text field for the comment? What is this and what is it asking me permission for?"). Nonetheless, it would certainly avoid wasting the user's time attempting to post somewhere they can't or showing them login screen when they don't even plan to add comments.

Jose Pedro Arvela added on

Forgot to say, on the last mockup, when clicking the "Change user name" link, it would/should simply reload the page with a new HTTP Authentication form so the user can choose a new Username and Password to use. If it is properly reloaded, luckily the comment area will retain the text inserted by the user (this would need to be tested tough).

append delete #4. sink

Allowing only certain users to post messages but still allowing everybody to read is a fairly unusual use case. It doesn't seem (to me, anyway) common enough to be worth adding much complexity to NNF.

Allowing full access to just a certain set of users and denying everybody else can already be done using existing tools in front of NNF and not having to muck with the NNF internals at all.

append delete #5. Kroc

Wow, great responses. Thank you everybody.

@theraje

“For each private forum, you could have a special members .txt file”

Yes, that sounds very much like NNF

@Jose Pedro Arvela

“A read-only forum and a private forum serve two different purposes, and the possibilities of each should be considered independently.”

Very astute, you are right. This gets all the more complex. If we are able to seperate each of the features clearly, then I’m sure we can come to a clean, simple design.

Also, thanks for going way, way out and putting that much effort into your reply!

“A private forum could simply have the login form beneath the title.”

That wouldn’t actually be necessary, and either way wouldn't look too good if there were several private forum; and also that same method wouldn't work for the root forum!

NOTE TO ALL:

HTTP_AUTH works by the page sending an authorisation request and the web browser will itself (i.e. not HTML) pop up a login box. When the user enters the right details, the browser will remember those details and will *continue to send them with every request* until the browser is closed or the cache cleared.

That means that HTTP_AUTH acts like a browser session, but tied to a username / password.

Therefore, for things like private forums, the user can click on a private forum and their browser will prompt for the name and password -- no need to do it in HTML, and then the browser will send the name and password every time so that they can *stay* in a private forum.

Remember that there's no session so that entering an HTML login form will only let you view ONE page before the name/password would be needed again, so that’s why HTTP_AUTH has to be used!

----

With that in mind,

“Regarding read-only forums, I think a good idea would be to use CSS to dim the comment form and show a warning message until both the username and password are filled. As shown in the following image:”

This is a good idea, but specific to a specific sub-set feature of limitation, which is Making the Forum Visible, but Limiting Users; rather than Private [Hidden] Forums.

There's two ways that can be handled. First is the way you have just shown. Show the post form, but tell the user it is limited. The second way is to not show the post form, but instead show a login button that invokes the HTTP_AUTH request. Once authenticated the form will show. (similar to your further mockups)

“Nonetheless, it would certainly avoid wasting the user's time attempting to post somewhere they can't or showing them login screen when they don't even plan to add comments.”

That is indeed my intention.

@sink

“Allowing only certain users to post messages but still allowing everybody to read is a fairly unusual use case. It doesn't seem (to me, anyway) common enough to be worth adding much complexity to NNF. ”

It is actually quite common on forums, usually the news or announcements forum where by the admin wants to post news articles, but doesn't want anybody else to post new threads in there, cluttering it up.

---

So, to summarise. What we have here is a few individual, related features:

1. The ability to limit posting to a specific userlist (e.g. members.txt)

2. The ability to make a forum private and hidden until login

3. The ability to prevent new users registering

I think you’ve all helped to make this a lot clearer in my mind.

Kroc added on

Another idea made possible by the availability of HTTP_AUTH is that moderator functions could be hidden until a moderator has logged in. (Put a "moderator log in" link at the bottom of the page or something). Also, once a moderator is logged in, then actions like delete and un/lock happen instantly without the login page inbetween)

append delete #6. Kroc

I have some questions over implementation:

Let's say we want to make a forum visible to all, but only allow select users to create new threads;

We could do this with a members.txt file. But how would that work in conjunction with mods.txt?

How would we distinguish between a forum that only certain people can create new threads, but anybody can reply to threads? (e.g. a news / announcements forum, or using a forum as a blog)

What mechanism (text file, config option, RSS data) should we use to set the following behavioural parameters?

1. A public forum that only mods can post to, and only allowed users can reply to (should allowed users == mods for the sake of simplicity? Is there a need for certain people posting and a different set of people replying?)

2. A public forum that only mods can post threads to, but anybody can reply to threads

3. A private forum that only specific people can access. (should this also use mods.txt for the user list?)

Perhaps this should be done with some sort of text file that the presence of sets the features for the forum / sub-forum. Like "private.txt", or "locked.txt" or a "mode.txt" with a string inside to set the options?

append delete #7. Martijn

“What mechanism (text file, config option, RSS data) should we use to set the following behavioural parameters?”

I propose something like this:

• Any name in mods.txt can read the forum and post in the forum.
• Any name in posters.txt is allowed to post in the forum. If this file is found anyone not on mods.txt or posters.txt is only allowed to reply.
• Any name in readers.txt is allowed to read and reply in the forum. If this file is found anyone not on mods.txt, posters.txt or readers.txt is not allowed access.

This keeps it to an easy file structure and all options can be mixed and are optional. Even using only readers.txt could have its uses for an archived forum or something. Because it’s using a clear hierarchy you don’t have to list several names multiple times either.

append delete #8. Jose Pedro Arvela

I think a single permissions.txt would be the ideal, with a structure similar to this (assuming HTTP-Auth is not used or is somehow compatible with this): 

% Example permissions.txt

%

This example is really simple:
The first three options define if a forum is private and/or read-only globally. These two situations can happen individually or at the same time.

Then the list of mods, who have all privileges. Then a list of people who can see the contents of the forum (if the forum is private), a list of people who can post new threads (if no posts are allowed) and a list of people who can reply to existing threads (if no replying is allowed).

I don't know how would it be possible to implement together with HTTP-Auth, but I now think HTTP-Auth is or will be a feasible and interesting alternative if or when browser makers make sure the important commodities of normal forms are available (mainly remembering what was typed into the box in the past and being tab modal).

I suppose each setting/list could be saved on an individual file, but that is irrelevant, what matters is knowing what to save, without duplicating info.

Jose Pedro Arvela added on

Here's what I originally typed into permissions.txt, that somehow got deleted due to non-breaking spaces (using Alt+255). 

%

%

Jose Pedro Arvela added on

And again: 

% 3rd try
Private true
Can-post false
Can-reply false
->Mods
Kroc
mod1
mod2
->Can-see
theraje
jj
Martijn
->Can-post
theraje
Martijn
->Can-reply
Martijn
%

(below is the original without being in block code)

Private true
Can-post false
Can-reply false

#Mods
Kroc
mod1
mod2

#Can-see
theraje
jj
Martijn

#Can-post
theraje
jj

#Can-reply
Martinj

append delete #9. Kroc

Odd thing with the code blocks there :S

I believe as you describe it is far too much granuality and just not simple enough for NNF. We have to trade off a little granuality for the sake of simplicity. e.g. Only mods can post new threads in a locked forum, rather than defining that list separately.

I see it in terms of these three forum attributes: (rather than lists of people)

* Posts Locked (cannot reply)
* Threads Locked (cannot start new threads)
* Private (not visible)

Then we just use mods.txt as the list of people allowed, i.e.

* If posts are locked, only mods can post new threads, and only mods can reply.

* If threads are locked, only mods can post new threads, but anybody can reply

* If the forum is private, only mods can access it

That way there's only one list of people. We just need a really simple way to choose one of those three forum attributes. Probably just a text file continaing "posts", "threads" or "private".

append delete #10. Martijn

The reason why I don’t think just mods.txt will do is because the people in that file will have the right to lock / edit / remove posts. I might want a ‘posts locked’ forum but make sure mods can’t go fighting amongst each other by appending to or removing each others’ content.

Posts locked forums are more common then you might think. There are many places where you first have to proof yourself as a user on other sub forum before being allowed to post in the main ones. These people are still normal members and should not be given moderator abilities.

append delete #11. Kroc

Yes, I was going to append that the main downside to using just mods.txt is that everybody in the sub-forum would be able to delete each other's posts :P

In the first two instances (public forum with locked threads or posts), then you only need a mods.txt since anybody who is going to be posting to a forum that is publicly viewable, but can only be posted to by specific people are for all intents mods anyway.

In the third instance, private forums, then yes, you do need to be able to distinguish between people who can access the private forum and those who moderate it.

In which case, I propose that for the third instance only (private forums) that a members.txt can be used in addition to mods.txt (in fact the presence of the members.txt file could be what tells NNF that the forum is private, as it's not needed in the other two instances).

Kroc added on

Correction: I didn't fully grasp your message and missed what you had said about a forum where by regular users can't post until they're let in.

Okay, so as an improvement to what I said above, let's say a members.txt file can optionally be used in any instance to limit the users who can post and another text file determines if the forum is post-locked, thread-locked or private.

How's that sound?

append delete #12. Kroc

Should global mods (mods of the root forum) be able to access private forums?

append delete #13. Kroc

Progress is going very well with this. I’ve finally managed to get my mind around the design I want.

There is a sign-in link in the footer that moderators (although anybody can use it) to sign in with HTTP_AUTH so that they are recognised as moderators (or whoever they are) continually as they browse. This allows for access control detection in the code to hide / show the input forms according to access; this way the input forms are hidden in locked threads / forums -- so the public can’t post, or get confused -- but a moderator can sign in and post. This also adds lots of new helpful features, like the ability for modeators to reply to locked threads, and delete posts in locked threads.

append delete #14. Martijn

Sounds like a great base Kroc! I still say we need some additional roles to moderator, but I guess with HTTP_AUTH completely implemented it would be easy to add whatever we want. We could even leave that up to the board administrators to implement; if they need more complexity—learn to code.

append delete #15. Kroc

Well, even as simple as I've made this, it's still quite hairy and the hardest part of the work is actually refactoring my own code over and over again to hone it down to some clarity. There are a lot of fringe cases one has to account for, and then implement as cleanly as possible without a million IFs everywhere.

For example, the append and delete links adhere to some complex behaviour:

- hidden if the forum is post-locked, but not to moderators
- hidden if the thread is locked, but not to moderators
- hidden on deleted posts, except for moderators
- visible on a post if it is by a signed-in owner, as long as the post is not deleted or the forum is post-locked and the owner is a member

Once I've got the code posted, I'll want to try refactor it further more for clarity and consistency, so it's easier for others to understand. It's important to me that after any large change NNF is thoroughly cleaned and pulled back into a tightly optimised and honed piece of code that's easy for others to read, understand and modify.

What I'd like to know actually is what people's use cases are for NNF, so instead of designing features for feature's sake, I'd like to know how people use NNF and what they need to achieve as far as their users are concerned so that I can design according to needs, rather than features; but that's for another thread I'll start.

append delete #16. Kroc

I’ve pushed what I’ve done so far to GitHub here https://github.com/Kroc/NoNonsenseForum/tree/http_auth if anybody wants a look. This is very untested, probably full of fringe-case holes, and needs a lot more refactoring to make it clearer to understand (especially with the crazy IFs in action.php)

append delete #17. Kroc

We’re running a pre-release version of NNFv8 now, notice the sign-in link in the footer :)

append delete #18. Martijn

Noticed it right away! Well, actually, I didn’t. I noticed the two new sub forums first ;)

It’s kinda unsettling to be able to login and no longer need to provide credentials every time I wish to post something. I guess I got used to NNF’s way of doing things very fast.

append delete #19. kroc

You can still do things the old way too :)

append delete #20. Kroc

Job done everybody, version 8 is released! http://camendesign.com/nononsense_forum

Thank you everybody who helped with hashing out the access control features, I think it turned out very well. :)

append delete #21. NickPfen

Is there an option for a completely private forum with NNF? As in, the user is prompted to see a login box before viewing or reading any threads or content within the forum?

NickPfen added on

I have found my answer over at the read me file next to the latest release of NNF. Has anyone come up with solution as stated in the read me section:

“If you want a private forum / sub-forum, protect the relevant directory
using ".htpasswd". Instructions are not provided here on how to
configure ".htpasswd" protection as it requires basic server admin
skills and some knowledge of using ".htaccess" files.

The users defined in the ".htpasswd" file will have to have the same
password as their NoNonsense Forum username.”

Reply

(Leave this as-is, it’s a trap!)

There is no need to “register”, just enter the same name + password of your choice every time.

Pro tip: Use markup to add links, quotes and more.

Your friendly neighbourhood moderators: Kroc, Impressed, theraje, Martijn