Forums / Developer / HOWTO dynamicaly add a volatile role to current user

HOWTO dynamicaly add a volatile role to current user

« 
Previous topic
|
Developer
|
Next topic
 »
Author Message

Sylvain Gogel

Friday 13 November 2009 2:11:39 pm

Hi there,

I'm building a system where users got a sub-section of the tree node they are allowed to see only if the user authenticate against a third tiers app.

The Third Tiers system login process involve a Web Service and i keep user informations in Session. Now i try to figure out how to give read access to the sub-section content tree during the session.

My idea was to programmaticaly add a role to the currentUser, this role cannot be persitant as when session expires current user must "loose" this role.

(User must login with the defaul ezp Auth system before accessing third-tiers system)

Any idea how i can acheave this?

--
http://www.ecedi.fr
Agence Web, Créa/Conseils, Accessibilité
eZPublish, Drupal, Zend, Symfony

Piotrek Karaś

Friday 13 November 2009 2:59:37 pm

It's quite possible I will be solving a similar problem soon. Maybe not exactly the same, but somewhere near. Anyways, I haven't done that yet so it's only a brainstorm.

As far as I know, user's privileges which are originally derived from user-usergroup-role setup, are after authentication written in a form of an optimized access array and stored as a session var. If you learn how this array is consumed by the system, you should be able to create an action or a view that will modify it as needed and I'm pretty sure this will make it possible to grant access to some subtree for example.

However, there is a problem. Every time anything changes about access control and/or role definitions or role assignments, all user sessions are signaled that they should regenerate their access arrays. So if that happens during your manipulated temporary access sessions, they are likely to get destroyed.

So you would either need to hack that system or maybe abandon this entire approach and simply try to dynamically create proper access control configuration of users, user groups, roles and role assignments. Then everything is pretty much native.

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Bertrand Dunogier

Friday 13 November 2009 3:51:20 pm

Hacking into the user roles is probably one of the worst approaches, sorry Piotrek :-)
It can stop working anytime when eZ Publish is updated, and it should be.

Now, that's a bit tricky. The dynamic role idea is very cool, but as far as my knowledge goes, it's not gonna be very easy to achieve. Depending on your performances requirements, you could achieve this very easily using a pre-read workflow. Don't hit me ! It would work fine. But it might be a bit of heavy weaponry. You will also face the ViewCache on this, since even if the role is made dynamic, it will still have the same idea, and it will be served from cache even if the role's content is disabled; you will probably have to disable it for these sections. Honesty, workflow is my suggestion. It won't prevent ViewCache from being used, and will be fully portable to next versions.

P.S. If the user can't see the content, you just have to return the HALTED status. To display custom refusal text, you can set the content that should be returned using the $this->Template property:

public function execute()
{
<span> </span>...
<span> </span>$this->Template['TemplateName'] = 'design:foo/bar.tpl';
<span> </span>$this->Template['TemplateVars'] = array(
<span>  </span>'var1' => $var1,
<span>  </span>'var2' => $var2 
<span> </span>);
<span> </span>return eZWorkflow::STATUS_CANCELLED;
}

I'm not 100% sure about the status handling, and it's getting a bit late here :-)

Bertrand Dunogier
eZ Systems Engineering, Lyon
http://twitter.com/bdunogier
http://gplus.to/BertrandDunogier

Sylvain Gogel

Friday 13 November 2009 4:16:56 pm

Hum i do not like hacking kernel (even if i did it a couple of time as you know bertrand)

I just HATE ezp workflows so if i can avoid it i can.

It's just too bad there is no simple way to extend the eZUser class to plug my own code in. I notice that Login Handlers have to extend the eZUser class too work. What will happen if i write a login handler that to not overload the loginUser() function but the role() method?

class eZEwmUser extends eZUser
{
   public function __construct() {}
   public function roles() 
   {
      $output = parent::roles();
      //add my stuff here to add volatile roles
      ....
      return $output;
   }
}

Will it acheave volatile roles?

--
http://www.ecedi.fr
Agence Web, Créa/Conseils, Accessibilité
eZPublish, Drupal, Zend, Symfony

Piotrek Karaś

Friday 13 November 2009 9:27:37 pm

"

Hacking into the user roles is probably one of the worst approaches, sorry Piotrek :-)
It can stop working anytime when eZ Publish is updated, and it should be.

"

Bertrand, I think I didn't make it clear enough, but of course I am against hacking. It is also approach that I rarely take because I usually find solutions that don't require that. I just wanted to illustrate a technical possibility, but you're right - I should have underlined that it's not recommended ;)

"

It's just too bad there is no simple way to extend the eZUser class to plug my own code in. I notice that Login Handlers have to extend the eZUser class too work. What will happen if i write a login handler that to not overload the loginUser() function but the role() method?

"

Sylvain, I think my description will still apply more or less.

"

My idea was to programmaticaly add a role to the currentUser, this role cannot be persitant as when session expires current user must "loose" this role.

"

 

Some more questions:

  1. Are your users registered eZ Publish users? Or do you want to just allow outside people to access something?
  2. Will that role be exactly the same for all the users?
  3. By loosing this role you mean he should never be able to login again?

And maybe yet another approach will be to create a dedicated module that will actually skip all the eZ Publish core and provide sort of an access layer that simply fetches content from eZ Publish and pushes it to the user. It could even have it's independent login form. But there are lots of risks in this approach, too.

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Sylvain Gogel

Saturday 14 November 2009 12:24:01 am

"

Some more questions:

  1. Are your users registered eZ Publish users? Or do you want to just allow outside people to access something?
  2. Will that role be exactly the same for all the users?
  3. By loosing this role you mean he should never be able to login again?

And maybe yet another approach will be to create a dedicated module that will actually skip all the eZ Publish core and provide sort of an access layer that simply fetches content from eZ Publish and pushes it to the user. It could even have it's independent login form. But there are lots of risks in this approach, too.

"

1. yea they are registered ezpublish users ( they cannot access third tiers login if not logged in)

2. yea same role for all users

3. No, i mean if session expire they must re login into the third tiers system, even if still logged in as a registered users

I was thinking about during third tiers login to dynamicaly add a persistant role, but they will keep it if they are logged out by session expiration and won't need to login again to access thoses private content

--
http://www.ecedi.fr
Agence Web, Créa/Conseils, Accessibilité
eZPublish, Drupal, Zend, Symfony

Bertrand Dunogier

Saturday 14 November 2009 1:38:30 am

Well, I can perfectly understand that you hate workflows. Even though I feel like asking why in that particular case. There are workflows and workflows. A multi-step, cronjobn involving workflow is very different as compared to what I suggested.

The thing is that you don't have many alternatives. I really tried thinking about the whole execution chain, with ViewCache etc, and unless you take the short path and disable everything, you will face these sooner or later. You won't with the pre-read workflow, and it will only be used as a hook here. Start by checking content/read, then the content/read operation, and you'll see that it's not very complex, and might be usable for you.

But it's your call :-)

Bertrand Dunogier
eZ Systems Engineering, Lyon
http://twitter.com/bdunogier
http://gplus.to/BertrandDunogier

Sylvain Gogel

Saturday 14 November 2009 11:07:10 am

Thanks for your answer Bertrand, j'apprécie beaucoup ton aide

First i don't like Workflows for the following reasons

  • I'm not at ease with it, the way it works the peaces of code involved
  • I got some bad xp with content locked into a workflow with no way to reset the workflow etc
  • I got some bad xp with payment workflow
  • The terms used are quite frightening, Multiplexers
  • Back Office Workflow UI is really a crap (Hope ez4.3 will really have a good BO UI refactoring)

I wonder the perf impact of a pre-read workflow but i will give a serious look at it, do you have any pointers to start with pre-read workflows?

ps: btw is there some screenshot of the future 4.3 BO?

--
http://www.ecedi.fr
Agence Web, Créa/Conseils, Accessibilité
eZPublish, Drupal, Zend, Symfony

Bertrand Dunogier

Saturday 14 November 2009 12:18:46 pm

"

First i don't like Workflows for the following reasons

  • I'm not at ease with it, the way it works the peaces of code involved
  • I got some bad xp with content locked into a workflow with no way to reset the workflow etc
  • I got some bad xp with payment workflow
  • The terms used are quite frightening, Multiplexers
  • Back Office Workflow UI is really a crap (Hope ez4.3 will really have a good BO UI refactoring)

I wonder the perf impact of a pre-read workflow but i will give a serious look at it, do you have any pointers to start with pre-read workflows?

ps: btw is there some screenshot of the future 4.3 BO?

"

I'll try to answer some of the points the best I can :-)

Let's begin by the end: I don't think much is currently visible regarding the 4.3.0 BO. Everything that is available should already be on SVN, but this has to be checked.

Regarding workflows:

  • I came to use them quite early in my learning curve, as I was a former user of other CMS that used workflows a lot. Once you get used to it, they're not that complex. It of course depends on their features... the API can be a pain in the ass, I agree. On the other hand, they're quite similar to datatypes, when you look a bit deeper into their API.
  • Yes, workflows that use the cronjob are much more sensitive... but you don't need that here. The workflow event itself could be quite simple: check if content can be read. If it can, return ACCEPTED status, if it can't, REFUSED status + custom message. No cronjob has to be harmed in the process ;)
  • Payment workflows yes... bad experiences here too :p
  • Yeah, just think about the multiplexer as a workflow hub. This does sound frightening too, damn.
  • Well, you don't use it everyday, just to set your workflow up.

It is true that writing a full featured workflow extension is not an easy job. But the most difficult part comes when you want to make your workflow configurable using the backoffice. If you implement the whole logic using INI files + code, you don't have to do that. It just comes down to PHP code. If you need a backoffice and feel more safe that way, you can perfectly write a custom module with its own backoffice tab, and implement your system's configuration here using custom tables. You'll still be able to pull this data from your workflow event code.

About pointers, you don't need much:

  • enable the content/read workflow in workflow.ini (IIRC)
  • the API is the same than for other events; just use before/read in the constructor
  • start with a print_r of $event & $process. The parameters are in $process as far as I remember

You can still ask here again if you run into an issue. And if something's broken, well, it's better to fix it, right ? ;)

Bertrand Dunogier
eZ Systems Engineering, Lyon
http://twitter.com/bdunogier
http://gplus.to/BertrandDunogier

Sylvain Gogel

Wednesday 18 November 2009 11:45:19 am

Next week i will give a try to the workflow event, based on section + tiers system login

How will the search engine (ezfind based) will handle visibility based on pre-read workflow?

--
http://www.ecedi.fr
Agence Web, Créa/Conseils, Accessibilité
eZPublish, Drupal, Zend, Symfony

Bertrand Dunogier

Thursday 19 November 2009 1:36:51 am

"

Next week i will give a try to the workflow event, based on section + tiers system login

How will the search engine (ezfind based) will handle visibility based on pre-read workflow?

"

That's a very interesting question ! Simple answer: it won't by default.

How do you intend to implement section based visibility in your workflow ? I'm almost sure we can find a way to get eZ Find to filter out results, but not without more details.

Bertrand Dunogier
eZ Systems Engineering, Lyon
http://twitter.com/bdunogier
http://gplus.to/BertrandDunogier