silverstripe-restfulapi
silverstripe-restfulapi copied to clipboard
Current Member data + related data example
I'm wondering if there are examples of retrieving data that relates to the currently authenticated member (via log in then using token). For my app I want to get list of all the 'logs' link to a member via a has_many relationship.
So each log has a has_one to a Member, so a MemberID attribute? So when you login you get the current member ID (here 9) and attributes.
So a GET request like /api/log/?MemberID=9
should do the trick? Assuming Log
is the class name....
You might also be able to get it via /api/Member/9
and enable embedded records for Member...
Sure that could work. But I want an authenticated member to only be able to access their own logs... I assume that if I opened that up as above they could edit the url and access any peoples logs...
That would be done through your normal canView
checks.
If you set access_control_policy: 'ACL_CHECK_CONFIG_AND_MODEL'
(https://github.com/colymba/silverstripe-restfulapi/blob/master/doc/RESTfulAPI.md) the api will check those canView/Update...
methods on your dataObject. There you can check that whoever is accessing it is the right Member owner of those logs.
With the token auth, the Member that sends the api request gets logged in, so canView can act on it accordingly.
Does that make sense?
Hi, sure, seems to, I'll have a go. Cheers!
@jonshutt I'm having the exact same use-case in my current app. So maybe my extension can be useful to you: https://gist.github.com/bummzack/2a6c5a3109a4ada75b1c
thanks - didn't progress this for a long while, but i'll check out your extension. cheers
I'm trying to do similar and can't get this to work.
Seems like canView, etc - relate to the class of object not the specific object itself or am I missing something? For example if I call $this->ID inside the canView function I get null.
@tscole the canView/Delete/Update..
methods are called multiple times during the query lifecycle.
Sometimes very early when handling the API request where the ID isn't known yet, in those case the can
method will be called on a singleton
and the ID will not be available. But the check is more than often done again later in the request lifecycle and then it will be passed an actual DataObject
so the ID should be available. If you trace your can
checks, you should get more than 1 request to it.
For example, a DELETE
api request will call api_access_control
twice, once very early when starting to handle the request and before fetching the DataObject
from the database (then the check is done on a signleton) and it is called again a last time just before deleting the actual object (after the object was fetched from the DB). But in the case of a POST
request for example, you will never have an actual ID since we are creating the object...
Hope that makes sense :)
Ah, that makes sense. Thanks for responding! I will amend my code and see how I get on.