63 replies to this topic

[Jelmer]

I have recently implemented the new capabilities of Etomite regarding front-end user authentication and permissions checking. I managed to create the following:
- The members of my band find a 'login' link on our website.
- After logging in, an extra part becomes visible in the menu, which contains pages only logged-in users are able to view.
- The 'login' link turns into a 'logout (username)' link

This is a small HowTo for anyone who wants to achieve it. If you follow these steps it should be a piece of cake!

PLEASE NOTE: I've only tested this on Etomite 0.6.1 Final (Prelude) with the latest patches installed.

PLEASE ALSO NOTE: Despite this howto, the used snippets and methodology is very advanced. Only use the techniques if you have an idea on what you're doing. If you have no experience with using the existing user permissions, please read the documentation on the subject first: http://docs.etomite.com/administration-use...ermissions.html

Here's what I did:

1. I patched my index.php to use the updated checkPermissions API function.
http://www.etomite.com/index.php?s=...ost&p=34849

2. In the Etomite manager, I enabled both 'access permissions' and 'visitor permissions'. To redirect page requests from un-authenticated users I changed the 'access denied message' to

<script type="text/javascript">location.href='accessdenied.html'</script>

where 'accessdenied.html' is the alias + friendly URL suffix of the page where I tell people the have to log in and redirect them to the login page.

3. I added the snippet 'authenticate_visitor' (http://www.etomite.com/index.php?showtopic=4867) and I patched it with the recent security fix (http://www.etomite.com/index.php?showtopic=5706). Then I made a slight modification. I changed the line

// PROCESSING STARTS HERE

// if the user is authenticated and no destination was provided, provide a logout button.
// this conditional code block is optional and can be remarked or bypassed
if($_SESSION['validated'] && $use_logout)
{
  if(isset($_POST['logout'])) $etomite->userLogout($url,$id,$alias="");

to

// PROCESSING STARTS HERE

// if the user is authenticated and no destination was provided, provide a logout button.
// this conditional code block is optional and can be remarked or bypassed
if($_SESSION['validated'] && $use_logout)
{
  if(isset($_POST['logout'])||isset($_GET['logout'])) $etomite->userLogout($url,$id,$alias="");

4. I created a new user role 'member' with no manager permissions at all.

5. I created a new usergroup called 'members' and a documentgroup 'restricted memberpages' and matched the two.

6. I created a bunch of users for my members with the role 'member' and gave them 'members' (the usergroup) permissions.


7. I created a login page (login.html) and a page with an 'Access Denied' message (accessdenied.html), both NOT CACHABLE and containing a call to the login snippet: [ ! authenticate_visitor ! ]

8. I once again read the tutorial Ralph wrote on the subject (http://dahlgren.slyip.com/e_v_a_101.html) and amended my menu snippet. I'm using the MollioSecondary menu and have attached the edited snippet. It now always displays the documents that don't require authentication. When logged in, it displays the non-authenticated documents, the documents that only require authentication and the documents that require permission and the logged in user happens to have the right ones.

Ralph also edited the ListMenu snippet to do the same (http://www.etomite.com/index.php?s=...ost&p=34849) so that should help in amending your own menu snippet. If you don't succeed, attach the code here (don't paste it in your post, I'll delete those) and we'll help.

9. Finally, I added the documents and folders I want to protect from the public. On the 'publication' tab I checked 'Authenticate?' and on the 'permissions' tab I checked 'restricted memberpages' (the documentgroup I created earlier).

10. To make thinks a bit fancy, I created a little snippet I called LoginOut, which is attached to this post and I include it like [ ! LoginOut ! ] somewhere in my template.

11. Unless I've forgotten something, you should be up and running!

Attached Files

•  MollioSecundaryMenu.php   4.63K   87 downloads
•  LoginOut.php   794bytes   75 downloads

Edited by Jelmer, 01 August 2006 - 08:39 PM.

[Jelmer]

What's the point of hiding your documents for the general audience if they keep popping up everywhere?

Attached to this post you'll find:

- An updated version of the ListSiteMap snippet (0.6h, the version that ships with Etomite 0.6.1 Final)
- An updated version of the GoogleSiteMap_XML snippet (0.6, also the version that ships with Etomite 0.6.1 Final)

Please let me know if there are other crucial snippets that need to be compatible with front-end permissions.

Attached Files

•  ListSiteMap.php   4.19K   50 downloads
•  GoogleSiteMap_XML.php   9.73K   36 downloads

[Jelmer]

OK If you want it even more fancy, how about welcoming the logged-in user with his username or full name? See the attached file.

Attached Files

•  Name.php   452bytes   56 downloads

[ruben]

What are the opinions on users changing their password in the front-end?
Are there security vulnerabilities? How to avoid these?

[Jelmer]

I think Bacteria Man was busy with something like that : http://www.etomite.com/index.php?showtopic=4855

[Ralph]

There aren't any security issues as long as you poll for the existing password in yourpassword change form... I have just such a snippet which may be floating around in the forums but not in the snippet library... I'll write myself a note to review the snippet and get it into the library...

[ruben]

The reason I posted my question in this threat is because I used Jelmer's idea on dealing with user permissions in the front-end of the website.
I coded to snippets to get the change-password procedure ok in the front-end.
Only logged-in visitors with the right permissions will be able to visit the pages where s/he can change the password. Thus in my case, the password check takes place with users logging in. This user group has changing and saving password permissions. If you think a double-check for the current password is necessary then please warn me!

The first snippet simply is the form from the etomite core that is used to enter the new password (and confirm it). The second snippet is adapted from the mutate_password.dynamic.action.php.
The two snippets are used by different files: the first (containing the form) is visible in the menu tree, the other is not visible in the menu tree.

Attached Files

•  changepassword_front_end.php   2.3K   49 downloads

Edited by ruben, 11 August 2006 - 03:21 PM.

[Ralph]

My fully tested snippet is located here... All text prompts are stored in variables which makes adapting to different languages easy... It also includes injection security and more than adequate permissions and role checking...

[Jelmer]

A not yet fully tested snippet for requesting a new Password is here : http://www.etomite.com/index.php?showtopic=5807. I could use some feedback!

[ruben]

Ralph, nice snippet. It's better than mine, so it's implemented on my site!
Jelmer, I'll give it a try soon!

[Jelmer]

That's indeed the approach I'd take as well. You could get the current user's group like this:

$internalKey = $_SESSION['internalKey'];

$group = "3" // the group that you are looking for

if($userData = $etomite->getIntTableRows(
		$fields="*",
		$from="member_groups",
		$where="user_group=".$group." AND member=".$internalKey,
		$sort="",
		$dir="ASC",
		$limit="1",
		$push=true,
		$addPrefix=true))
		
{ $output .= "Extra options..."; }

Haven't tested it, but it should work...

[Ralph]

@Jon...

You are correct in your theory that user actions are controlled through Roles... Roles determine what a person can do system-wide... Document Group permissions only control who has access to what... There is no built-in means of performing user by user Role permissions on a document by document basis, however... You can either go somewhere or you can't and you can either do something or you can't... There is no way to say that when you visit one page you have these permissions but when you go to another page you have different permissions... Those unconventional permissions logic decisons would require custom coding at the snippet level just as you have been implementing...

[SmileyBri]

I think this thread relates to what I want to do, and I have searched the forum for topics related to this, so if it has been asked and answered please refer me to a specific post if you would.

I don't care about privileges to edit a document, I want to three types of access to read documents, or even be able to see the links to them in the navigation if possible.

Public
Member
Subscriber

This thread is discussing ways to accomplish this as hacks to the default system, so I assume the functionality does not currently exist in Etomite? Is it expected in an upcoming release?

If not I might hack away, but isn't this kind of functionality basic to a CMS? The level of sophistication in the users, roles and permissions to create rules for who can edit what is fantastic, but not what I need specifically. Is there a CMS as good as this that does what I am looking for?

Thanks in advance.

[ruben]

I understood that this will be part of the core of the next version.
Please correct me if I'm wrong.

[Jelmer]

Whether it's basic to a CMS depends on your definition. It's definately standard in a portal, which Etomite is _not_.

But what you want can definately be achieved using the information in this topic. As a matter of fact, I'm using the same functionality!

[Jim Browski]

Hi there,

i made a fresh install of etomite 0.6.1.2 and followed the instructions ... mostly. I did not update the index.php (1) as mentioned because i supposed eto 0.6.1.2 already contains the one with the new permission API. All the other steps i followed word by word and added the authListMenu and the LogInOut-Snippet to my template.

First it seemed to work. I can login as a member, but then i still have no access to my so-called "member-area". And when i log in i got redirected to my "login-failed.html"-page, but the snippet on that page shows me that i have successfully logged in.

This behaviour can be seen at my eto testsite:
http://test.bildcontext.org/etomite2/
I generated two members, the first as "member1" with pwd "testme", the second as "member2" with pwd "member2".
The Login-Link is at the bottom right, and the Member Area is the last point at the menu. For testing purposes now the standard ListMenu is used again.

It would be nice if someone could take a look and give me some advice. If it's necessary i also could provide access to the manager.

Edited by Jim Browski, 23 October 2006 - 10:55 PM.

[Ralph]

Jim Browski, on Oct 23 2006, 06:46 PM, said:

I did not update the index.php (1) as mentioned because i supposed eto 0.6.1.2 already contains the one with the new permission API.

You really need to update the index.php file as that is the actual parser... If you don't update that file you may as well not update at all... The new parser should be virtually 100% backwards compatible with any snippets you currently have with the exception that visitor permissions now work as I had originally intended and no longer need additional work-arounds... Or did I misunderstand your post in that you didn't upload the old version of the parser that is present in the package...???

[Jim Browski]

Ralph (rad14701), on Oct 24 2006, 02:00 AM, said:

... Or did I misunderstand your post in that you didn't upload the old version of the parser that is present in the package...???

Thanks for the reply.
As i'm no english native speaker sometimes it's hard for me to say exactly what i'm thinking of
Sorry for that. I think there is some misunderstanding.

I do use the index.php file that is shipped with the download package of eto 0.6.1.2.
I do not use the modified index.php file Jelmer in the orginal post has linked to.

Is this wrong?

The rest of Jelmers posting i followed step by step ...