Current Member data + related data example about silverstripe-restfulapi

[colymba]

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...

[jonshutt]

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...

[colymba]

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?

[jonshutt]

Hi, sure, seems to, I'll have a go. Cheers!

[bummzack]

@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

[jonshutt]

thanks - didn't progress this for a long while, but i'll check out your extension. cheers

[tscole]

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.

[colymba]

@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 :)

[tscole]

Ah, that makes sense. Thanks for responding! I will amend my code and see how I get on.