Authorization before showing wiki

[Tabitha Samuel]

Hi,

I'm using django-wiki as a part of a larger user portal which is authenticated via Duo. I've already made the hooks for Django-wiki to redirect to the portal login page for authentication instead of using the inbuilt login mechanism. My question is two fold:

1. I only want a subset of authenticated portal users to be able to view the wiki. Everyone else should get a "You are not authorized to view this page" message when they try to access the wiki.

2. I want only a subset of authorized users of the wiki to have write privileges, everyone else should only have read privs.

How do I accomplish this? Thanks for your help!

Regards,
Tabitha

[Benjamin Bach]

Dear Tabita,

The wiki is made to work with Django's default authentication system that consists of Users who can be members of Groups. You can assign Group access and add all your subset of users who HAVE privileges to one Group, and then make sure that all the users who don't have access aren't in that group.

Then set the privileges for the root page (see screenshot)

Best,
Ben

--
You received this message because you are subscribed to the Google Groups "django-wiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-wiki...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tabitha K. Samuel]

Ben,

Thank you very much! That is extremely helpful. This gets me most of the way there. This solves the issue of differentiating between users who can edit and who can only read. The outstanding issue is that out of all the users who can successfully authenticate, only a subset of them are authorized to view and/or edit the wiki. I don't see a way to manage multiple group permissions here, that is, control which authenticated users can access the wiki, and then further subdivide into who can read and who can write. I hope that makes sense.

Regards,

Tabitha

To unsubscribe from this group and stop receiving emails from it, send an email to django-wiki+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "django-wiki" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-wiki+unsubscribe@googlegroups.com.

[Benjamin Bach]

Nope, this part of user administration is for you to either implement or use the Django Admin's auth interface:

http://<host>/admin/auth

django-wiki deliberately avoids providing such functionality, because project needs are highly individual, and it's impossible to create a "one size fits all" - Django itself doesn't do that, neither.

Best,
Ben

[Tabitha K. Samuel]

Makes sense. So what I'm trying to do is to catch the request before it is passed to the view in the wiki/urls.py file and add a authorized decorator to the view call. For example:

url('^$',
                self.article_view_class.as_view(),
                name='root',
                kwargs={'path': ''}),

becomes

url('^$',
                authorized(self.article_view_class.as_view()),
                name='root',
                kwargs={'path': ''}),

Problem is that the /wiki doesn't seem to pass through any of these URL patterns. Printing out URL patterns coming from this file looks like:

([<RegexURLPattern root ^$>, <RegexURLPattern root_create ^create-root/$>, <RegexURLPattern root_missing ^missing-root/$>, <RegexURLPattern search ^_search/$>, <RegexURLPattern diff ^_revision/diff/(?P<revision_id>\d+)/$>, <RegexURLPattern signup ^_accounts/sign-up/$>, <RegexURLPattern logout ^_accounts/logout/$>, <RegexURLPattern login ^_accounts/login/$>, <RegexURLPattern profile_update ^_accounts/settings/$>, <RegexURLPattern deleted_list ^_admin/$>, <RegexURLPattern change_revision ^_revision/change/(?P<article_id>\d+)/(?P<revision_id>\d+)/$>, <RegexURLPattern preview_revision ^_revision/preview/(?P<article_id>\d+)/$>, <RegexURLPattern merge_revision_preview ^_revision/merge/(?P<article_id>\d+)/(?P<revision_id>\d+)/preview/$>, <RegexURLPattern get ^(?P<article_id>\d+)/$>, <RegexURLPattern delete ^(?P<article_id>\d+)/delete/$>, <RegexURLPattern deleted ^(?P<article_id>\d+)/deleted/$>, <RegexURLPattern edit ^(?P<article_id>\d+)/edit/$>, <RegexURLPattern preview ^(?P<article_id>\d+)/preview/$>, <RegexURLPattern history ^(?P<article_id>\d+)/history/$>, <RegexURLPattern settings ^(?P<article_id>\d+)/settings/$>, <RegexURLPattern source ^(?P<article_id>\d+)/source/$>, <RegexURLPattern change_revision ^(?P<article_id>\d+)/revision/change/(?P<revision_id>\d+)/$>, <RegexURLPattern merge_revision ^(?P<article_id>\d+)/revision/merge/(?P<revision_id>\d+)/$>, <RegexURLPattern plugin ^(?P<article_id>\d+)/plugin/(?P<slug>\w+)/$>, <RegexURLResolver <RegexURLResolver list> (None:None) ^(?P<article_id>\d+)/plugin/attachments/>, <RegexURLResolver <RegexURLResolver list> (None:None) ^(?P<path>.+/|)_plugin/attachments/>, <RegexURLResolver [] (None:None) ^_plugin/attachments/>, <RegexURLResolver [] (None:None) ^(?P<article_id>\d+)/plugin/notifications/>, <RegexURLResolver [] (None:None) ^(?P<path>.+/|)_plugin/notifications/>, <RegexURLResolver <RegexURLPattern list> (None:None) ^_plugin/notifications/>, <RegexURLResolver [] (None:None) ^(?P<article_id>\d+)/plugin/macros/>, <RegexURLResolver [] (None:None) ^(?P<path>.+/|)_plugin/macros/>, <RegexURLResolver [] (None:None) ^_plugin/macros/>, <RegexURLResolver <RegexURLPattern list> (None:None) ^(?P<article_id>\d+)/plugin/images/>, <RegexURLResolver <RegexURLPattern list> (None:None) ^(?P<path>.+/|)_plugin/images/>, <RegexURLResolver [] (None:None) ^_plugin/images/>, <RegexURLPattern create ^(?P<path>.+/|)_create/$>, <RegexURLPattern delete ^(?P<path>.+/|)_delete/$>, <RegexURLPattern deleted ^(?P<path>.+/|)_deleted/$>, <RegexURLPattern edit ^(?P<path>.+/|)_edit/$>, <RegexURLPattern preview ^(?P<path>.+/|)_preview/$>, <RegexURLPattern history ^(?P<path>.+/|)_history/$>, <RegexURLPattern dir ^(?P<path>.+/|)_dir/$>, <RegexURLPattern settings ^(?P<path>.+/|)_settings/$>, <RegexURLPattern source ^(?P<path>.+/|)_source/$>, <RegexURLPattern change_revision ^(?P<path>.+/|)_revision/change/(?P<revision_id>\d+)/$>, <RegexURLPattern merge_revision ^(?P<path>.+/|)_revision/merge/(?P<revision_id>\d+)/$>, <RegexURLPattern plugin ^(?P<path>.+/|)_plugin/(?P<slug>\w+)/$>, <RegexURLPattern get ^(?P<path>.+/|)$>], u'wiki', u'wiki')

Any idea where the final "u'wiki', u'wiki'" is coming from? Any help at all would be greatly appreciated! Thanks!

Regards,

Tabitha

[Benjamin Bach]

Wouldn't it work by just removing read access to everyone outside of the group?

On 07/19/2018 04:55 PM, Tabitha Samuel wrote:

Hi,

I'm using django-wiki as a part of a larger user portal which is authenticated via Duo. I've already made the hooks for Django-wiki to redirect to the portal login page for authentication instead of using the inbuilt login mechanism. My question is two fold:

1. I only want a subset of authenticated portal users to be able to view the wiki. Everyone else should get a "You are not authorized to view this page" message when they try to access the wiki.

2. I want only a subset of authorized users of the wiki to have write privileges, everyone else should only have read privs.

How do I accomplish this? Thanks for your help!

Regards,
Tabitha

--
You received this message because you are subscribed to the Google Groups "django-wiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-wiki+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.