Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upUser role based access for APIs #1165
Conversation
pliablepixels
referenced this pull request
Nov 17, 2015
Closed
Make sure zmNinja plays ball with new user roles in APIs #93
pliablepixels
changed the title from
Implemented user based access for Monitors APIs
to
User role based access for APIs
Nov 17, 2015
kylejohnson
reviewed
Dec 2, 2015
| { | ||
| $options = array ('conditions' => array ('User.Username' => $loggedinUser)); | ||
| $userMonitors = $this->User->find('first', $options); | ||
| $this->Session->Write('allowedMonitors',$userMonitors['User']['MonitorIds']); |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
kylejohnson
Dec 2, 2015
Member
I haven't read up on this in a while, but what do you think of Session->Write vs. Configure::write? I am using the latter in other places.
kylejohnson
Dec 2, 2015
Member
I haven't read up on this in a while, but what do you think of Session->Write vs. Configure::write? I am using the latter in other places.
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
pliablepixels
Dec 5, 2015
Contributor
@kylejohnson , based on my reading:
Configure::write is for application wide variables while Session->Write is for settings that get set only for that specific session. The latter is what we need for these variables as they will change depending on who has opened the session
pliablepixels
Dec 5, 2015
Contributor
@kylejohnson , based on my reading:
Configure::write is for application wide variables while Session->Write is for settings that get set only for that specific session. The latter is what we need for these variables as they will change depending on who has opened the session
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
kylejohnson
Dec 3, 2015
Member
Overall this looks pretty good.
Maybe I'm not reading the AppController class right - but how does a user actually log in to the API?
|
Overall this looks pretty good. Maybe I'm not reading the AppController class right - but how does a user actually log in to the API? |
kylejohnson
added
the
Not Ready for Merge
label
Dec 3, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
pliablepixels
Dec 5, 2015
Contributor
@kylejohnson - the user does not log into the API. The user logs into ZM. This sets a set of variables - I am accessing those variables in the context of the same session to make sure the user has logged in.
|
@kylejohnson - the user does not log into the API. The user logs into ZM. This sets a set of variables - I am accessing those variables in the context of the same session to make sure the user has logged in. |
pliablepixels
added some commits
Dec 8, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
pliablepixels
Dec 19, 2015
Contributor
I'm closing this as PR #1196 supersedes this and adds OPT_API to UI too
|
I'm closing this as PR #1196 supersedes this and adds OPT_API to UI too |
pliablepixels commentedNov 17, 2015
@kylejohnson please review interim progress (Please label Not Ready to Merge) #1155
So far I've implemented user roles for the Monitors API. If this approach is ok, I'll continue down this path.