session cookie conflict

[Amiramix]

I am using Zotonic as a frontend to another application with its own login/logoff mechanism. I am setting the user_id and auth_user_id in the context and session to something arbitrary so that it can persist between page refreshes. I noticed that when I log in to the admin section the session still thinks it is the old user, not an user from the admin section. For example it crashes on DB constraints saying that my user_id is not in the database rsc table. I understand the problem is because the cookie is set for the whole domain, not just the section admin.

So my question is if Zotonic expects the same users that are accessing the main website (e.g. with the Sign Up module) should be able to access the admin section. For example if module ACL Simple Roles is enabled instead of Admin Only, would users be able to log in to the main website and the admin section using the same logon form? Or should the admin section have a separate set of users independent of the users of the main website? If the later then shouldn't the session and context be able to handle two separate sessions somehow?

I guess in my case the solution would be to store the user id using the custom prop list in the session and not the standard user_id/auth_user_id keys? In that case the admin section would be able to set them to whatever is needed. Would that be the expected implementation or more like a hack?
Many thanks for any help.

[Marc Worrell]

Hi,

The ACL modules indeed assume that the user_id/auth_user_id keys are valid users.
Valid users have a page (person) record in the database.

I normally add a new ACL module if we need special access controls that the two default modules don't deliver.

Is the other application part of zotonic or something completely separate?

BTW, the session is always present, so you don't need to store anything in there to keep it alive.

- Marc

[Amiramix]

Thanks Marc for a quick reply!
No, it is a separate Erlang application which keeps their user names and logins in a different database. I just need to store the other user id (which in the other application is called role) somewhere in the session/context so that I can check if the user is logged in to view specific Zotonic pages (this is done by a custom is_authorized that checks if the user is logged in in the other application).

So I guess I just need to store the user id somewhere else than the default user_id/auth_user_id?

[Marc Worrell]

On 19 sep. 2012, at 21:55, Amiramix wrote:

> Thanks Marc for a quick reply!
> No, it is a separate Erlang application which keeps their user names and logins in a different database. I just need to store the other user id (which in the other application is called role) somewhere in the session/context so that I can check if the user is logged in to view specific Zotonic pages (this is done by a custom is_authorized that checks if the user is logged in in the other application).
>
> So I guess I just need to store the user id somewhere else than the default user_id/auth_user_id?

Yes, just add it as a key in the session. Just try not to use those two keys :-)
Maybe app_role or something.

You can then fetch it from the session when you need it, and maybe cache it in the Context with context:set/get
Then you don't need to call the session process every time you need the app_role.
(This is just an optimization… don't make it too complex at first)

- Marc

[Amiramix]

OK, thank you, that's very helpful. But coming back to my original question, do you expect to have the same users accessing the admin section and the main website? Or the sing up and acl simple roles also store the user_id somewhere else than the default user_id/auth_user_id?

[Marc Worrell]

On 19 sep. 2012, at 22:30, Amiramix wrote:

> OK, thank you, that's very helpful. But coming back to my original question, do you expect to have the same users accessing the admin section and the main website? Or the sing up and acl simple roles also store the user_id somewhere else than the default user_id/auth_user_id?

Yes, we assume that all the admin users are also users of the web site.
It is just that they have some extra privileges to use the admin (and/or system configuration).

- Marc

[Amiramix]

OK, thanks, that explains a lot.

[Amiramix]

Marc, I need to come back on this. It looks like lots of things in Zotonic don't work properly if the user isn't a proper Zotonic user, e.g. authorization when accessing REST through API. If I wanted to add a custom ACL module do I still need to store the user in the rsc table?

As far as I can see Zotonic assumes that a user is authorized if user_id in the #conext isn't set to undefined. Can I write a custom ACL module to store the user in the context but not in the PostgreSQL database?

[Marc Worrell]

Hi,

I think you should be able to use the #context fields user_id and acl for other purposes.

As long your 

But note that some template assume that the user_id is also a resource id.

And as such can be dereferenced to show the name of the user etc.

Regarding the user_id values, there are a couple of assumptions.

- user_id 1 is the administrator.

- when the acl is set to 'admin', we are inside a "sudo" action.

In the oauth stuff, called by the api controller I found the following:

%% TODO: Refactor: Should be done via z_notifier

This is in the place where some checks are made.

I think the oauth module should be decoupled from the api controller.

Especially as the api controller directly calls into mod_oauth.

That should solve your authentication problem.

Maybe Arjan know more about this (he added both modules/controllers).

- Marc

[Amiramix]

As I wrote in the other thread, maybe there should be a module that would manage users, e.g. return its name given an id? Or if user is an admin user?

I agree that OAuth should be decoupled from the controller_api. But should that be don with z_notifier instead? I don't know Zotonic architecture that well. From what I see in the code first of all controller_api checks if the user is already logged in by checking if user_id is set to something (which is bad for other modules if the user isn't stored in the rsc table). Only after that it tries to use the OAuth module.

[Andreas Stenius]

Wouldn't it be easier if you had a module that simply populated the rsc table with some data from the external source?

That way you can use the user_id field without shooting yourself in the foot.

2012/10/6 Amiramix <li...@gjunka.com>

[Amiramix]

Unfortunately not because of a few reasons. Firstly in the external system users can be added or removed using a command line, independently from Zotonic. Secondly, because those users don't follow the Zotonic way of defining users - where there is just a user and password. They follow the use of roles like in PostgreSQL, where each role may be a member of other roles. Additionally each role may have attributes. Then if a role is authorized to view a resource (or download the JSON API file) depends also on other roles and those attributes. I would need to sync all that data to Zotonic's rsc table, which seems a bit of overkill.

If Zotonic has to have all their users in the rsc table then the easiest way of fixing this particular problem is forking the controller_api file and defining my own is_authorized, in which I can call the external system. And do it for any other module or resource that require users to be in the rsc table. Which is exactly what I was trying to avoid.