Hidding the navigation panel for anonymous users

[tobias]

It would be really nice to hide the nav panel especially when the wiki is only accessible to registered users. In a corporate environment that would be a no go (at least here in Germany) with potential clients. The best way would be to hide all sites which require permissions in the panel.

[SteveB]

By sites, you mean pages, right? Why don't you just setup different sites that require login before any information is visible?

[tobias]

yes, I meant pages. Of course, I can add a login page in front of the wiki but then I have the problem of users having to sign in twice. First at the front page and than in the wiki (of course, you could get this down to one but that requires programming skills).

[pnicolai]

+1

If a page is private and only viewable by certain users / groups, it should not appear in the nav panel for any other users / groups that don't have permission to view it. The title of the page is part of the page, so the current permissions model actually doesn't allow making any page completely private.

[SteveB]

Please read previous posts on this matter.

[pnicolai]

You've said this to me twice now; trust me, I did search before posting. Since you say it's covered before, I read all the headings of all the threads of this foru m and haven't found anything on this particular topic. I'm interested though; since you know which posts you're talking about, if you have a minute I'd appreciate it if you could post links to the posts you are referring to. I'm sorry if my efforts to find this information through the search function have been incompetent somehow, but please be assured I did make an effort to find anything like this before posting.

[SteveB]

I replied twice since you posted twice! :)

Anyway, after spending 30 minutes looking in vain for my old post, I gues I'll just reiterate it here:

Page title are hierarchical, meaning that the title of the parent page is part of the title of the child page. Consequently, if you have page "A" being private, but page "B" not being private, then we can't enfore the rule that A should not be visible.

The problem is further compounded by the fact that we show page paths quite frequently. For instance in the Recent Changes view, for related pages, for tagged pages, for searches, and the list goes on. So, "hiding" titles is not an easy issue.

[pnicolai]

That makes sense - that's kind of why I was naively thinking you could substitute "<restricted>" or something for the hidden parts of the path, but that wouldn't help with URLs obviously and probably a lot of other stuff. Searches are a whole other mess - I think this is a common security hole in wikis actually.

It would just be really nice to have some way to occasionally show pages to outside people without letting them see all the titles to the other pages in the wiki, and unless there's something I'm missing I don't think it's possible with DekiWiki. Some wikis have the concept of 'spaces' which probably makes this a little easier. DekiWiki's toplevel pages could be like spaces, but to really enforce that might require a new kind of access restriction that couldn't be overridden by child pages and implies real permissions, so it would apply to searches, recent changes, anything involving access to the page. I imagine this would involve a much more comprehensive permissions system than the current method of access control though.

Earlier in the thread you suggested setting up multiple sites, but it's a lot of work to set up a whole new wiki every time you want to show one thing to someone. It would be much easier if you could just make a new toplevel page that that person has rights to and then move or copy the page there. If I've also made several other similar toplevel pages for other outside people, they can all see the titles of each others' pages, which isn't ideal or even acceptable in many cases.

Let me know if there's some other way to do this that I just haven't caught on to though.

[SteveB]

Actually, the permissioning system in Hayes supports it, but it's not exposed. In Gooseberry, we had this concept of "invitations". A person with an invitation can only see pages to which he/she has been invited to. Of course, we can't hide the parent page, but that's an acceptable limitation. All other pages will be hidden from view, including in search results and RSS feeds (this, by the way, already works now; if you set a page to 'private' it will not show up in search results, recent changes, RSS feeds, etc.). We want to bring back the "invitation" feature eventually, but for now, we're focusing on polishing what is already in the product and making sure it works great.

[pnicolai]

The invitation system sounds like it would do the trick. Not being able to hide the parent page is fine as long as you can hide other toplevel pages & their children including their titles in the nav tree.

Re polishing: from what I've seen so far you guys are doing a great job of that - the usability is pretty amazing. It's possible we could make do with emailing PDF exports to people for some things but for others it would be a stretch. hoping for invitations...

[mreuvers]

By sites, you mean pages, right? Why don't you just setup different sites that require login before any information is visible?


The multiple wikis solution isn't really a solution IMHO. It's a dirty hack :) When we installed MediaWiki we ran into the exact same problem, and we solved it by using this hack. We were hoping that Deki Wiki really solved it.

To be honest for our company the whole access rights system is totally useless if people can still see the page structure including topic names. If you tend to have a lot of sub-pages of your 'secret' document, people can more or less understand what your secret document is all about by simply looking at the topic names! And I'm sure we'll breach all kinds of NDAs if this problem cannot be solved :)

[...]


Of course, we can't hide the parent page, but that's an acceptable limitation.


What exactly do you mean with 'hiding the parent page'. Take the following example:

Root
-Article 1
-Article 2 [private]
--Article 2.2
-Article 3


What will be visible to all users?

Root
-Article 1
-Article 2
-Article 3


or

Root
-Article 1
-Article 3


?

Obviously I'd prefer the latter case.

[SteveB]

If you navigate to 2.2, your URI will look as follows:
http://yourwiki/Article_2/Article_2.2

So, "Article 2" will be show in the URI and in the navigation bar. We can't hide parent pages in the navigation pane, b/c it would break the navigation.


BTW, did you see this suggestion for hiding pages? http://forums.opengarden.org/showpost.php?p=2747&postcount=3

[pvanzelst]

Hi, I'm working on the same wiki site as mreuvers.
I think there may be a misunderstanding here (perhaps the question wasn't phrased precisely enough). What we want to do with the access restrictions is prevent access to (and even seeing titles of) entire sections of the wiki.

As in mreuvers' example:

Root
-Article 1
-Article 2 [private]
--Article 2.2
-Article 3

What we mean is we want "Article 2" and everything that lies below it to be private. Furthermore, we don't want it to show up in the site map or the navigation bar on the left, if the user that is logged in doesn't have access to those pages. As mreuvers already indicated, even seeing the titles of a certain page hierarchy could give away a bunch of information we'd really like to keep private.
So this is not an issue of wanting subpages to be public, but still make parent pages private (which seems to me like a silly thing to do anyway).


[Edit: About the suggestion for hiding pages: yes, I've seen it, and tried it out. It seems to come close to what we want to do, with a few minor issues. The pages that are private can no longer be viewed, the titles of the sub-pages aren't shown, and it doesn't show up in the site map, all of which is great. However, when viewing the site map, users do get a 403 error at the top of the screen, and the private parent page still shows up in the navigation bar on the left.]

[SteveB]

Ok, so the change almost worked. Let's work through the remaining issues, which should be easy to track down, and you'll be dog heaven. :)

[pvanzelst]

But how should I go about tracking those issues down? :) My Deki Wiki hacking skills are non-existent.

[SteveB]

We make it really simple for you: when you see that something isn't quite right, take a screenshot and post it here. We'll make sure it gets addressed and can then provide a patch to verify it for yourself. Sound good? :)

[pvanzelst]

haha alright, that makes me feel a bit too incompetent ;)
It's not that I can't program (I'm a professional game programmer), or don't know PHP. I'm just not familiar with the intricacies of Deki Wiki. However, I have poked around the MediaWiki source code a bit, when I was trying to make that work for our purposes (crudely hacking in multiple project support, which essentially just used completely separate databases to retrieve data from, as an alternative to access restrictions).

When we stumbled across Deki Wiki, it turned out that this was a much better match for what we wanted than MediaWiki (the MediaWiki philosophy apparently being 'keep everything open', which doesn't really work in a corporate environment with NDAs everywhere). Now it's just a matter of modifying some bits here and there to make it completely fit our purposes; access restriction being of highest importance.

That said though, Deki Wiki appears to be more complex (both in internal structure and technologies used) than MediaWiki, which is why I'm not too confident in my ability to find and modify things myself (I was a web developer back when the whole 'web 2.0' and AJAX hype didn't exist yet, so I didn't catch any of that).

To make a long post longer, I will follow up on your advice and post screenshots of something that doesn't seem quite right.
I've changed the permissions for the "Private" restriction to remove the BROWSE permission. I've set the access restriction to "Private" for one page in the wiki (named "Confidential Page") and all its subpages ("Secret Nested Page"). I have two test users in this wiki: one administrator and one contributor. I only granted the administrator access (which seems kind of redundant, but oh well).
After setting the access restrictions, the administrator could still see the page in the navigation bar and in the site map, which is as it should be:
http://www.divinedev.com/dekiwiki/access_control/with_access_combined.png

However, when logging in as the contributor, things are different. As is expected, this user does not see the "Confidential Page" in the site map:
http://www.divinedev.com/dekiwiki/access_control/sitemap_no_access.png

But, the user does see the "Confidential Page" in the navigation bar on the left:
http://www.divinedev.com/dekiwiki/access_control/mainpage_navbar_no_access.png

The contributor cannot do anything with the "Confidential Page" (cannot see underlying pages, cannot view the article), but it should not even show up in the navigation bar. The way it is now, the user can still catch a glimpse of the page that he should not even know exists.

[tobias]

Any updates on this?
I am facing the same problems as pvanzelst. Will there be an update in Hayes+?

[SteveB]

BrigetteK is fixing issues related to making pages disapear across the site when users don't have the BROWSE permission (BROWSE means they can see titles, but nothing else). This should be fixed in Hayes+ (unless we hit some kind of deeper issue). Stay tuned!

[brigettek]

I am working to address the issues mentioned by pvanzelst for Hayes+. The caveat is that you will still need to perform the update described in http://forums.opengarden.org/showpos...47&postcount=3, since there will not be a UI for changing the definition of page restrictions in our upcoming Hayes+ release.

[tobias]

I have no problem changing one value in a table as long as the rest is working :)

The thing is that we want to use one wiki for different groups of people who are not supposed to see anything except their content. If you can fix the problem mentioned by pvanzelst, I will happily change one row in a table!

[SteveB]

In newer releases of Deki Wiki (1.8.2a and later), the value for the "private" restriction has no longer the BROWSE bit set. This means that nobody can browse the titles of restricted pages now.