Thanks Heath. I meant "dual login" by the fact that a user would have to log in once to the main site, but then log in again to their own group of pages.

So, I realise that you can set up different permissions for different users so that they can only see / modify the sections that they have permissions for, but I specifically want the user workflow to be:

user unable to see any of the site except landing page >> login1 >> now user can see certain pages but not modify anything >> login2 >> now user can see all pages but can only modify specified pages that they have permissions for.

Admin >> login1 >> can see and modify everything

I hope that makes it clearer what I am trying to achieve.

I will of course look through the documentation and figure it out, but I wanted to know if it is possible to do it this way.\

While I understand a little more what you mean now by "Dual login" the idea sounds horrific.

You should not need to login twice. I can't imagine a good system which would technically require this and I know users would -hate- such an annoyance.

Within eZ Publish, you would not need to login twice. You would just need to create the right roles (and combinations of policies).

Take a look at the content, read policy controls available by default, they sounds like just what you need. Hint this would require changes to the anonymous role's policies to customize them to provide for what your describing.

I wanted to add that almost anything is possible within eZ with enough custom development, eZ is just that extensible. That said not every first idea we can do means is a good idea.

After some much needed sleep last night I woke up and realized a use case that might make more sense to me and users, "Requiring users to confirm their password when trying to edit certain content". That is a use case that I as a user would not find offensive.

I thought it would be fun to see what it would take to implement a redirect to, 'confirm user password' page / processing before redirecting to content/edit view solution because this idea seemed interesting.

Edit: The follow advise / suggestions are version specific and were made for legacy. This is my first most this morning and my mind was still stuck in legacy mode. If your using new stack only eZ Publish or eZ Platform the solution will be drastically different.

I was hoping their would be a workflow event trigger for content/edit which would make this simple but sadly their I could find none.

I did a bit of research to find out what this might require and due to the nature of content/edit dependencies in the kernel I think this feature would require fairly substantial kernel overrides at a class level and possibly at a module level as well. I could be missing a simpler way to do this with little code but I was looking to integrate.

This point you would be able to inject code to test for prior successful custom password confirmation, then if not already confirmed, redirect to a custom module view (say: confirm/password) to display the user confirmation password prompt, which would submit to confirm/validate which would redirect back to content/action with the previous request parameter variables using, "$module->redirectToView( 'edit', $parameters );" within the if block described previously testing for successful custom password confirmation (session var of some kind?).

This would be a simple way of building into the existing solution securely with less kernel overrides.

You might be able to fake this with less work (using a legacy custom module view extension) but to do this securely overall I think it will be more involved than you will want to invest in at this point.

Another option is a custom module view custom action handler but it would not ensure this feature was secure and not able to work around with url hacking.