a REST API question

37 views
Skip to first unread message

Amiramix

unread,
Oct 6, 2012, 2:25:15 PM10/6/12
to zotonic-d...@googlegroups.com
What's the difference between controller_api, which is in the mod_base, and mod_rest?

I'd like to use controller_api to provide some JSON files but I can't use the default is_authorized that is defined in that module because I am using an external authorization (my users are not stored in Zotonic database). Copying the other methods and creating my own controller would rather prove that Zotonic isn't flexible enough so I am trying to avoid that. Can anybody please suggest a simple and effective solution? I don't mind adding some code to Zotonic if needed.

Marc Worrell

unread,
Oct 6, 2012, 4:04:40 PM10/6/12
to zotonic-d...@googlegroups.com
Hi,

controller_api is for access to the services in the modules.

controller_rest_rsc (in mod_rest) is an experimental controller for REST like access to resources.

Did you implement your own ACL module?

- Marc

Amiramix

unread,
Oct 6, 2012, 5:35:15 PM10/6/12
to zotonic-d...@googlegroups.com
No, I implemented my own controller with custom is_authorized method. Then I store the userId in a custom field in the context. But I think implementing my custom ACL module may be a good idea as long as I don't have to store the user in the rsc table and still have the rest of Zotonic working correctly. Currently some of the modules assume that the user is stored in the rsc table and I am afraid that even if I implement my own ACL module I still won't be able to use those modules.

Thanks for the explanation. I think I need to use controller_api because the data I need to return as JSON come from an external database and not from the rsc table. So I have the problem that the controller_api checks if the user is logged in by checking if user_id in the context is not undefined. In my case is undefined because I am using a custom field.

I think there are three ways of dealing with this problem:

1. In other modules don't assume that the user is stored in the rsc table
2. Have a separate module that would store and manage users in the system (not necessarily in the rsc table) and use that module in other modules
3. Don't assume that the user is stored in user_id field in the context
Reply all
Reply to author
Forward
0 new messages