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 <stor...@gmail.com> 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.picker...@gmail.com tel:+260968395190 _______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
