Received: by 10.58.212.198 with SMTP id nm6mr4566362vec.35.1349699852868;
        Mon, 08 Oct 2012 05:37:32 -0700 (PDT)
X-BeenThere: zotonic-developers@googlegroups.com
Received: by 10.220.141.4 with SMTP id k4ls4290194vcu.8.gmail; Mon, 08 Oct
 2012 05:37:32 -0700 (PDT)
Received: by 10.52.96.71 with SMTP id dq7mr2501630vdb.11.1349699852419;
        Mon, 08 Oct 2012 05:37:32 -0700 (PDT)
Date: Mon, 8 Oct 2012 05:37:31 -0700 (PDT)
From: Amiramix <li...@gjunka.com>
To: zotonic-developers@googlegroups.com
Message-Id: <cd8e2031-4008-43b6-afd1-801ae502f1ca@googlegroups.com>
In-Reply-To: <CABCxKrdQT7_S5TzJaAjYKDxjMwL4A-NDP+i_7x-gqukSrxgwhw@mail.gmail.com>
References: <42e82900-8611-40d3-ba6e-eed32e7e8ed1@googlegroups.com>
 <4FE458B7-B998-4CC0-975E-B44FC5C73E05@me.com>
 <1b9cfca4-5f93-4ea7-92cc-a348b2cf9961@googlegroups.com>
 <8BFA4515-92D9-47BB-A070-7AC84D2C8DA3@me.com>
 <af775c13-2298-4450-b1f5-54f168f0e718@googlegroups.com>
 <CABCxKrdQT7_S5TzJaAjYKDxjMwL4A-NDP+i_7x-gqukSrxgwhw@mail.gmail.com>
Subject: Re: [Zotonic-Dev] session cookie conflict
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_1066_19650793.1349699851936"

------=_Part_1066_19650793.1349699851936
Content-Type: multipart/alternative; 
	boundary="----=_Part_1067_23463165.1349699851938"

------=_Part_1067_23463165.1349699851938
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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.


On Sunday, October 7, 2012 8:12:52 AM UTC+1, Andreas Stenius wrote:
>
> 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 <javascript:>>
>
>> 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.
>>
>>
>> On Saturday, October 6, 2012 9:16:33 PM UTC+1, Marc Worrell wrote:
>>>
>>> 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
>>>
>>>
>>>
>>>
>>> On 6 okt. 2012, at 20:33, Amiramix wrote:
>>>
>>> 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?
>>>
>>>
>>> On Wednesday, September 19, 2012 8:49:15 PM UTC+1, Marc Worrell wrote:
>>>>
>>>> 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 
>>>>
>>>> On 19 sep. 2012, at 21:42, Amiramix wrote: 
>>>>
>>>> > 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. 
>>>> > 
>>>>
>>>>
>>>
>
------=_Part_1067_23463165.1349699851938
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Unfortunately not because of a few reasons. Firstly in the external system =
users can be added or removed using a command line, independently from Zoto=
nic. 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 ro=
les like in PostgreSQL, where each role may be a member of other roles. Add=
itionally each role may have attributes. Then if a role is authorized to vi=
ew a resource (or download the JSON API file) depends also on other roles a=
nd those attributes. I would need to sync all that data to Zotonic's rsc ta=
ble, which seems a bit of overkill.<br><br>If Zotonic has to have all their=
 users in the rsc table then the easiest way of fixing this particular prob=
lem is forking the controller_api file and defining my own is_authorized, i=
n which I can call the external system. And do it for any other module or r=
esource that require users to be in the rsc table. Which is exactly what I =
was trying to avoid.<br><br><br>On Sunday, October 7, 2012 8:12:52 AM UTC+1=
, Andreas Stenius wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Wouldn=
't it be easier if you had a module that simply populated the rsc table wit=
h some data from the external source?<div>That way you can use the user_id =
field without shooting yourself in the foot.<br><br><div class=3D"gmail_quo=
te">
2012/10/6 Amiramix <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"kTPfKmU-ExcJ">li...@gjunka.com</a>&gt;</sp=
an><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">
As I wrote in the other thread, maybe there should be a module that would m=
anage users, e.g. return its name given an id? Or if user is an admin user?=
<br><br>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 architect=
ure that well. From what I see in the code first of all controller_api chec=
ks if the user is already logged in by checking if user_id is set to someth=
ing (which is bad for other modules if the user isn't stored in the rsc tab=
le). Only after that it tries to use the OAuth module.<div>
<div><br><br>On Saturday, October 6, 2012 9:16:33 PM UTC+1, Marc Worrell wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-w=
ord">
Hi,<div><br></div><div>I think you should be able to use the #context field=
s user_id and acl for other purposes.</div><div>As long your&nbsp;</div><di=
v><br></div><div>But note that some template assume that the user_id is als=
o a resource id.</div>
<div>And as such can be dereferenced to show the name of the user etc.</div=
><div><br></div><div>Regarding the user_id values, there are a couple of as=
sumptions.</div><div>- user_id 1 is the administrator.</div><div>- when the=
 acl is set to 'admin', we are inside a "sudo" action.</div>
<div><br></div><div><br></div><div>In the oauth stuff, called by the api co=
ntroller I found the following:</div><div><br></div><div><div><span style=
=3D"white-space:pre-wrap">=09</span>%% TODO: Refactor: Should be done via z=
_notifier</div>
</div><div><br></div><div>This is in the place where some checks are made.<=
/div><div><br></div><div>I think the oauth module should be decoupled from =
the api controller.</div><div>Especially as the api controller directly cal=
ls into mod_oauth.</div>
<div><br></div><div>That should solve your authentication problem.</div><di=
v><br></div><div>Maybe Arjan know more about this (he added both modules/co=
ntrollers).</div><div><br></div><div>- Marc</div><div><br></div><div><br>
</div><div><br></div><div><br></div><div><div><div>On 6 okt. 2012, at 20:33=
, Amiramix wrote:</div><br><blockquote type=3D"cite">Marc, I need to come b=
ack 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 RE=
ST through API. If I wanted to add a custom ACL module do I still need to s=
tore the user in the rsc table?<br>
<br>As far as I can see Zotonic assumes that a user is authorized if user_i=
d 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?<br>
<br><br>On Wednesday, September 19, 2012 8:49:15 PM UTC+1, Marc Worrell wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">Hi,
<br>
<br>The ACL modules indeed assume that the user_id/auth_user_id keys are va=
lid users.
<br>Valid users have a page (person) record in the database.
<br>
<br>I normally add a new ACL module if we need special access controls that=
 the two default modules don't deliver.
<br>
<br>Is the other application part of zotonic or something completely separa=
te?
<br>
<br>BTW, the session is always present, so you don't need to store anything=
 in there to keep it alive.
<br>
<br>- Marc
<br>
<br>On 19 sep. 2012, at 21:42, Amiramix wrote:
<br>
<br>&gt; I am using Zotonic as a frontend to another application with its o=
wn 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 sessi=
on 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 f=
or the whole domain, not just the section admin.
<br>&gt;=20
<br>&gt; So my question is if Zotonic expects the same users that are acces=
sing the main website (e.g. with the Sign Up module) should be able to acce=
ss the admin section. For example if module ACL Simple Roles is enabled ins=
tead of Admin Only, would users be able to log in to the main website and t=
he admin section using the same logon form? Or should the admin section hav=
e 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 sepa=
rate sessions somehow?
<br>&gt;=20
<br>&gt; I guess in my case the solution would be to store the user id usin=
g the custom prop list in the session and not the standard user_id/auth_use=
r_id keys? In that case the admin section would be able to set them to what=
ever is needed. Would that be the expected implementation or more like a ha=
ck?
<br>&gt; Many thanks for any help.
<br>&gt;=20
<br>
<br></blockquote></blockquote></div><br></div></div></blockquote></div></di=
v></blockquote></div><br></div>
</blockquote>
------=_Part_1067_23463165.1349699851938--

------=_Part_1066_19650793.1349699851936--