Improve stoa authentication webservice.
fields are fields like image_base64 and tags, which are not in fact person fields and, therefore, have no interface in order to configure their privacy. Since any field that has no privacy configuration is now considered private on Noosfero, we created this class to overcome this problem.
fields are the ones that might be too big for constant traffic. The
fields are: image_base64
These are classes of fields from which the client will be able to choose to retrieve on the request.
none: no information at all. Should return just the confirmation of the authentication.
essential: login, email, usp_id.
essential fields, name, first_name, surname, address and homepage.
complete: every field without the
complete with the
- Optional data delivery: provide a way for the request to specify the data it wants in return. We might create some classes of request like
full, to avoid too much traffic of unnecessary information.
- Privacy respect
- Private profile: if the profile is private, we should provide only the
essential informations, even if the client request more.
- Private fields: the private fields should not be shared unless they are
- 04 Oct 2013
The idea of
fields was desconsidered.
- 21 Oct 2013
Here is how the feature would work.
The user/service makes a request through ssl with the user
parameter will define the group of fields Noosfero will return from the user. As described above, the available fields are:
. Each of this options returns a set of fields defined above. If no fields parameter is passed, the default used is the
So for example, if you want to have all the fields without the heavy one, that is the
option, you should make a request more or less like this one:
curl -d "login=ze&password=test&fields=complete" https://myserver.com/plugin/stoa/authenticate/
Or if you want to get every field, including the
ones, that is the
option, you shoud do:
curl -d "login=ze&password=test&fields=full" https://myserver.com/plugin/stoa/authenticate/
- 29 Oct 2013
Seems to work ok! Just some remarks:
- the tags return do not respect privacy settings. This event http://alpha.colivre.coop.br/ze/blog/evento is private, has a "volleyball" tag and is returned by the webservice. Is this on purpose? Or should we never return tags on private articles?
- Is the 1931/02/18 for birth_date the accepted date format for json? (I don't know)
- I understand it is a bit late to ask now, but I was thinking wether we could return de community memberships. This would allow some further integration of Moodle and Noosfero.
One strange thing I noticed is that the webservice continues to work even with the Stoa plugin turned off. This may be useful (the service is not dependent on the USP number if you user login=ze&password= etc.) but seems like unexpected behavior.
Another unexpected behavior is that a nonsense values for the key and values like &fieldsfsdfds=dfsd do not return an error.
- 31 Oct 2013
Hey Ewout, I'll just use the order of issues you pointed as 1, 2, 3; as we did on the other AI to make it easier to discuss.
- The private articles tags was indeed an issue. I'll fix it.
- Yes, every field is being converted to json on the api response. Also for date we use the ISO 8601 format which is pretty common for api's.
- It's not too late. As I said the infra allows easy inclusion of fields. I just need you to tell me in which class of field it'll go in (average or complete) and the format of the communities (id and name, I guess?).
- Uhm, that's a bug. This is happening because the routes are generated on the system level, so they are available if the plugin is enabled on the system. But there should be a verification on ApplicationController level. I registered this bug here: http://noosfero.org/Development/ActionItem2884
- This is in fact the expected behaviour. We should not crash the request if some random and unimportant parameter is passed. It'll be just ignored. The response works because it uses the default value for "fields" which is "essential".
- 04 Nov 2013
2. I think ISO 8601 specifies dates like this 1931-02-18, not like this 1931/02/18
3. I think community membership should go in the "complete" category. On the Moodle side I would use the name and the URL. I don't know what the id is, but I don't think it would be very useful for external consumption, if it is an internal noosfero thing.
I get curl: (7) couldn't connect to host while trying to test it. I think there is a problem with the secure web server on alpha.colivre.coop.br
- 18 Nov 2013
I'll fix the date and the communities result.
This error is because I need to do that hotfix to avoid ssl verification since our test server does not have it.
- 19 Nov 2013