Translations: English
Search on Docs:
ActionItem Search:

#2832: Improve Stoa webservice

Type: FeatureItem Feature:   Tags: stoa
ScheduledFor: 0.46.0 Assigned to: RodrigoSouto Sites:  
Priority: 0 Status: Done  

Improve stoa authentication webservice.



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


heavy fields are the ones that might be too big for constant traffic. The heavy fields are: image_base64


These are classes of fields from which the client will be able to choose to retrieve on the request.

  1. none: no information at all. Should return just the confirmation of the authentication.
  2. essential: login, email, usp_id.
  3. average: essential fields, name, first_name, surname, address and homepage.
  4. complete: every field without the heavy ones.
  5. full: complete with the heavy ones.


  1. 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 none, essential, average, complete and full, to avoid too much traffic of unnecessary information.
  2. Privacy respect
    1. Private profile: if the profile is private, we should provide only the essential informations, even if the client request more.
    2. Private fields: the private fields should not be shared unless they are essential or custom.

-- RodrigoSouto - 04 Oct 2013

The idea of sensitive fields was desconsidered.

-- RodrigoSouto - 21 Oct 2013

Here is how the feature would work.

The user/service makes a request through ssl with the user login, password and fields parameters. The fields parameter will define the group of fields Noosfero will return from the user. As described above, the available fields are: none, essential, average, complete and full. Each of this options returns a set of fields defined above. If no fields parameter is passed, the default used is the essential option.

So for example, if you want to have all the fields without the heavy one, that is the complete option, you should make a request more or less like this one:

curl -d "login=ze&password=test&fields=complete"

Or if you want to get every field, including the heavy ones, that is the full option, you shoud do:

curl -d "login=ze&password=test&fields=full"

-- RodrigoSouto - 29 Oct 2013

Seems to work ok! Just some remarks:

  • the tags return do not respect privacy settings. This event 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.

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

  1. The private articles tags was indeed an issue. I'll fix it.
  2. 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.
  3. 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?).
  4. 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:
  5. 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".

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

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

-- RodrigoSouto - 19 Nov 2013
Add comment
You need to login to be able to comment.

ActionItemForm edit

Title Improve Stoa webservice
ActionItemType FeatureItem
Priority Low
Tags stoa
Plugin StoaPlugin
ResponsibleDevelopers RodrigoSouto
ScheduledFor 0.46.0
Status Done
Ticket SAC:
who cares PauloRMM
Topic revision: r1 - 22 May 2015, UnknownUser

irc Talk with Devs Now!

Copyright © 2007-2019 by the Noosfero contributors
Colivre - Cooperativa de Tecnologias Livres