dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

Thanks Jo. :).  Guess I should have read the curl manual. :) That
worked like a charm. I have very, very basic needs at this point,
which consist essentially of being able to trigger data mart export
and report table generation at a scheduled time. That's it. Perhaps
2.0.6 will take care of it, but in the meantime, curl can press the
button for me. Of course, having a more cleanly defined series of REST
services would be very useful I think, but I am not sure the demand is
huge.


Regards,
Jason


On Mon, Nov 8, 2010 at 6:49 AM, Jo Størset <storset@xxxxxxxxx> wrote:
>t
> Den 7. nov. 2010 kl. 15.12 skrev Jason Pickering:
>
>> I think the automated data marts is a good feature, and might fit for
>> some users, but I can imagine situations where multiple actions might
>> need to be take place. Such as execute the data mart, execute some
>> report tables, export some data to CSV and save it in a certain place,
>> conduct a data integrity check and save the results as HTML...etc etc.
>>
>> I saw the commit from Jo on basic HTTP authentication. Jo, could you
>> explain how and if this works?
>
> From 2.0.5, Basic authentication should be done if you send the authorization header with the request, so there should be no need to do the cookie/forms login stuff from scripts.
>
> I.e. curl -v -u user:password url
>
> We can't serve up a 401 request unless you serve up the header, as we want the form based authentication to be the default (replying with a redirect).
>
> With the next version of spring security (3.1), I think it will be easier to have multiple authentication configurations. I was hoping that we could then have Basic as the default for the path/to/dhis/api/ namespace then, and maybe slowly start providing more clearly defined api-services. If people have simple and clearly defined services they need, I can try to take a stab at implementing them as prototype service, there. It has to simple, though, as I don't have much time and don't know the domain model considerations that well.
>
> I'm not completely sure if we really want to have basic as a default enabled for other urls. Basically I think we need to have this kind of stuff more generally configurable, but that is then a bigger task.. There is of course also the question of wether basic (and forms login) is acceptable for a web app without ssl, which people don't seem to use in the wild. I have been contemplating wether we should optionally support digest authentication (openROSA is considering making that a requirement for their mobile api [1]), but that is a headache when it comes to storing the passwords.
>
> [1] http://groups.google.com/group/openrosa-workgroup/browse_thread/thread/f7a431b7f50ddb3
>
> Jo
>
>



-- 
Jason P. Pickering
email: jason.p.pickering@xxxxxxxxx
tel:+260968395190