15:04:31 #startmeeting Development IRC meeting 24 June 2015 15:04:31 Meeting started Wed Jun 24 15:04:31 2015 UTC. The chair is cait. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:04:31 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:04:31 The meeting name has been set to 'development_irc_meeting_24_june_2015' 15:04:34 absinth hmmmm 15:04:36 #topic Introductions 15:04:37 #info wahanui, a bot that has become sentient 15:04:38 #info Martin Renvoize, PTFS-Europe 15:04:45 please introduce yourself using #info! 15:04:46 #info Mirko Tietgen, Berlin, Germany 15:04:47 #info Tomás Cohen Arazi 15:04:56 #info Katrin Fischer, BSZ, Germany 15:04:57 #info Bernardo Gonzalez Kriegel 15:04:58 #info Julian Maurice 15:05:06 #info Nicole Engard, ByWater 15:05:13 #info Jonathan Druart 15:05:15 #info Alex Arnaud, Biblibre 15:05:35 today's agenda is here: 15:05:37 #link http://wiki.koha-community.org/wiki/Development_IRC_meeting_24_June_2015 15:05:46 thanks cait 15:05:51 #info Kyle M Hall, ByWater Solutions 15:06:29 I have an hour 15 - after that i need to hand over to tcohen - but maybe it will be enough :) 15:06:30 #info Olli-Antti Kivilahti, Vaara-kirjastot 15:06:54 let's move on 15:06:56 dev-meetings are that long? eeek 15:07:07 #topic RM 3.22 comments 15:07:16 Hi everyone 15:07:21 hi 15:07:22 #info Carmen Hernandez, Bywater Solutions 15:07:23 hello 15:07:23 que tal, ashimema 15:07:26 good day 15:07:33 hi tcohen! 15:07:33 or night 15:07:44 or the inbetween things 15:07:44 good day everyone :D 15:07:55 as you might have noticed, we've had some security bugs highlighted by rangi et al 15:07:59 at catalyst 15:08:31 they worked hard, along with frido, katrin and jonathan on having them solved -> tested -> pushed 15:08:38 so congrats :-d 15:09:07 i'd like to mention that my queue (PQA patches) has (and will) be bigger than I expected 15:09:28 I'm pushing around 10~ or more bugs each day, but the QA team is adding like 20 a day 15:09:42 Sorry about that ;) 15:09:47 Joubu++ :) 15:09:51 some of them are trivial and I just don't notice them at first sight 15:09:54 damn busy qa people :P 15:09:55 cait++ 15:09:57 Joubu++ 15:10:00 marcelr++ 15:10:03 khall++ 15:10:06 :) 15:10:24 i've been trying to work on the bigger ones 15:10:33 well done qa peeps.. 15:10:41 but it means I might lag stuff that should have been pushed already... 15:10:48 * ashimema not included.. he's been crap of late at QA 15:10:55 so 15:11:47 #info the RM considers 'normal' for patches on the PQA list to stay there for more than 2 weeks, if you think something needs to be pushed faster, please contact the RM personally 15:12:00 i do my best, you can be sure 15:12:07 I finished up the help files for 3.20 and while we're talking 3.22 those do need to go to master and 3.20 15:12:48 but this people just hates me and works too hard to make me look like i'm relaxed and doing nothing 15:13:22 nengard: yeah, I'll push the latest patches ASAP, as they missed the string freeze i delayed them a bit 15:13:31 no problem at all 15:13:44 just didn't know how to note them on the bug report - I put them as 3.20 but didn't want them to get missed in 3.22 15:14:17 no worries, chris knows they need to be on master so he waits to cherry-pick them 15:14:35 ok, that's it, I'm looking forward to the next topic so, questions? 15:15:02 questions to the rm? :) 15:15:03 complains? 15:15:22 switching topics 15:15:27 #topic RESTful API implementation 15:15:29 before you ask: it is cold in cordoba this days. and i ran out of jagermeister 15:15:29 no complaints!!! 15:15:38 #link http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13799 15:15:39 04Bug 13799: new feature, P5 - low, ---, julian.maurice, Needs Signoff , Add base for building RESTful API 15:15:56 #link http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13920 15:15:57 04Bug 13920: new feature, P5 - low, ---, julian.maurice, Needs Signoff , API authentication system - proposal 15:16:30 #link http://wiki.koha-community.org/wiki/New_REST_API_RFC 15:16:33 I complaint for jägermesiter 15:16:53 kivilahtio_: thanks 15:16:56 i am not sure where to start here best - has someone prepared something? 15:16:59 * Joubu send some Fernet to tcohen 15:17:09 Joubu: will work 15:17:10 * drojf sends chartreuse 15:17:19 stop getting the RM drunk ;) 15:17:23 heh 15:17:24 jägermeister deluxe, made by monks ;) 15:17:27 pastisssss 15:17:39 ok 15:17:46 * cait coughs to remind everyone of the meeting 15:17:49 lets talk about the implementation from jajm 15:17:56 i think bug 13799 is ready to go in master, if nobody complains about it 15:17:57 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13799 new feature, P5 - low, ---, julian.maurice, Needs Signoff , Add base for building RESTful API 15:18:25 I think there are some big issues reagrading logging 15:18:45 I think the way Mojolicious just kills the STDÓUT and STDERR is bad 15:18:59 this means that when we get issues with DBIx it is not visible in the Mojolicious logs 15:19:09 I have a patch to circumvent that but it is VERY hacky 15:19:24 kivilahtio_: can it be solved by using Koha::Logger? 15:19:33 that was my thought 15:19:34 Mojolicious dev's think that we should intercept all error everywhere and put them to the Mojo::Log 15:19:45 this is how it should be done in real world 15:19:52 but since Koha is not quite there yet... 15:20:14 I have a hack there and a script to make sure the code incisions in Mojolicious::Server (or whatever) are affecting 15:20:19 we should be able to tie it all together with MojoX::Log::Log4perl 15:20:26 maybe 15:20:36 and I have no problem going to prod with those, just a warning that the logging has very diferent expectations 15:20:50 I'm wary of this bug adding so many large files as dependancies.. 15:20:56 khall: that is just a wrapper for Mojo::Log I think. This doesnt reopen STDOUt STDERR 15:21:01 for instance.. we're now packageing two jQuery versions? 15:21:10 moustache templates. 15:21:16 ashimema: the Swagger2 UI is a standalone installation 15:21:17 handlebars js.. 15:21:22 and it feels like loads of others 15:21:27 ashimema: so that is specific to the Swagger2 UI -tool 15:21:30 I agree with ashimema 15:21:42 why add it to our repo in this one big bug. 15:21:45 in any case, I don't think that should be a blocker, but definitely something we should keep in mind 15:21:51 basically we could jus put them into gitignore or something similar 15:22:12 i am also worried about the dependencies - if this gets really hard to set up - then we got a problem (think how long sip patches take to get in) 15:22:13 okay, cait. 15:22:14 Is the very not koha api documentation actually worth all that extra cruft 15:22:33 ashimema: the cruft stays in its own place nicely and doesnt interfere with anything 15:22:53 i think the swagger is so worth everything 15:23:18 also.. I'm not seeing anyoen having clearly written guidlines on how to write api routes using it.. 15:23:19 cait: dependencies is a solved issue as far as I can tell, is that correct jajm? 15:23:32 Today I managed barely to publish something nice where the swagger2 plugin extension deals with all Koha permissions based on the Swagger2 api definition in Koha 15:23:39 I want to see that as part of the core reasoning behind this patch.. 15:23:52 so we can drive features directly from the swagger definitions 15:23:57 else it won't actualyl make writing routes any easier.. instead it will add burden. 15:24:03 cait, it's not hard to setup, thanks to robin, you only have to install 2 debian packages, and update the apache virtual host conf (or run the perl Makefile.pl process...) 15:24:26 tcohen: more thinking of things outside mojo - I got pretty confused where nginx and hypnotoads fit in :) 15:24:39 cait: they are just for testing/development 15:24:44 well... yes 15:24:55 cait: back then nobody was kind enough to publish any real server configurations 15:24:56 cait, hypnotoad/nginx stuff has its own bug now 15:24:57 that's why i was referring to the sip patches :) 15:25:24 i need to have an essy dev/testing environment too so we can have this moving on fast :) 15:25:30 cait: so I made my own for me and others to start using Swagger2 while waiting for tcohen to come up with the Plack verison of services 15:25:39 if you want me to qa something- i need to be able to set it up 15:26:22 I still don't like that we're bundling in all thos JS libs.. 15:26:23 jajm: But I digress. Setting up the Koha REST API is really difficult, since there is no ready virtual host configuration shared anywhere 15:26:27 jajm: Are the routes documented/listed somewhere? 15:26:35 why not pull them at clientside? 15:26:47 there simply is no need to package them all into this patch 15:26:54 Joubu: when you deploy the Koha REST API infrasturcture they are most grandoiously deocumented 15:27:04 go to v1/doc/index.html 15:27:13 and you will understand why we like Swagger2 :) 15:27:14 kivilahtio_, there is a virtual host conf in bug 13799 15:27:15 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13799 new feature, P5 - low, ---, julian.maurice, Needs Signoff , Add base for building RESTful API 15:27:31 ack.. 15:27:38 yes but someone should be able to have a look without having an install available 15:27:41 swagger does NOT document for you.. 15:27:46 you still have to document the api.. 15:27:58 Swagger builds an interactive client for you.. if you so choose it to. 15:28:19 ok, i think we have different things here: 1 setting up - jajm says it's easy :) 15:28:22 I have tested the patches yesterday in 15min max 15:28:26 Joubu, no there's nothing lke that actually, you could look at the swagger spec, but it's quite verbose 15:28:29 simlarly.. you don't need that client bundled in with the app.. it can be completely distinct.. 15:28:31 install + config, even with a wrong test plan :) 15:28:36 i.e. hosting the Swagger spec file is enough.. 15:28:48 then one can use thier favourite API tool to build a client.. 15:29:09 jajm: it would be great to have a wiki page with the different routes listed 15:29:26 jajm: ok, maybe I missed it before, still no explanation how to run the Mojolicious? 15:29:27 to know quickly what is available when/where 15:29:36 postman for instance can take a swagger spec and generate a client to test all routes. 15:29:45 jajm: or the reverse proxy configurations. 15:30:04 Joubu, it could certainly be generated automatically from the swagger spec 15:30:07 Joubu.. I dissagree with havig a wiki page 15:30:15 the swagger spec IS the spec.. 15:30:21 it's definative. 15:30:38 maintaining a seperate wiki page with them is just an extra burden 15:30:41 but I thnk we shoudl have something you can access without having an installation 15:30:44 can we do that? 15:30:49 At least during the dev step :) 15:31:04 can it be hosted on koha-community.org somewhere? 15:31:15 hm I am trying to get some summary 15:31:24 the swagger spec file is self contained.. we could host it anywhere.. 15:31:29 and version it ;) 15:31:29 Joubu: Put this http://pastebin.com/nP7c4PaU to this editor http://editor.swagger.io/#/ 15:31:34 excellent 15:31:37 one of hte questions was ease of setup - what is needed to get it running 15:31:51 do we have instructions on that? and is mojo enough or is something else needed? 15:31:57 kivilahtio_: that's a quite good answer :) 15:32:05 absolutely no wiki, like ashimema said, the Swagger definitions are the documentation 15:32:16 Joubu: come clarity 15:32:30 cait, 2 packages are needed: mojolicious and swagger2 15:32:48 Joubu: ATM the Koha swagger2 definitions are really slimly documented. We can add all kinds of cool documentation to the definition 15:32:51 #info 2 packages are needed: mojolicious and swagger2 15:32:53 exactly as kivi just said.. 15:33:04 he swagger spec file 'is the documentation' 15:33:20 jajm: so the next question was if we should include swagger in koha? (is that the js libraries?) is that another tool? 15:33:23 is can be used via loads of tools out there to generate a nice to read version.. 15:33:30 editor.swagger.io is just one example. 15:33:48 the crap that's been added to koha as part of this patch is another 15:33:53 postman is another 15:33:58 httpinspector another.. 15:34:02 the list goes on and on.. 15:34:15 I would say the spec file is all we should have in Koha 15:34:20 keep is simple 15:34:36 ashimema: I am sorry but I don't see your point here? those are only used when using the Swagger2 UI -tool? Is tehre something specific which burdens you with it? 15:34:47 the js libraries are the client side of swagger.. 15:34:51 it would at least ease the integration until we reach some consensus on how to expose the API docs 15:35:06 yes, it can always be pulled out later 15:35:27 #info Question: should we include the client side of swagger in Koha (for now) 15:35:30 khall I agree.. the spec file is the thing we should have in koha.. 15:35:30 tcohen: the Swagger2 UI -tool is super awesome in testing the API 15:35:33 cait, Swagger2 is a Perl module and a Mojolicious plugin, aside from that there is Swagger UI, which allows to see the documentation and test the api at the same time 15:35:40 we don't need to embed the entire demo client builder 15:35:41 #idea only keep the spec file in Koha so it can be used with different tools 15:35:47 please correct me if i put nonsense int he logs 15:35:57 it's Swagger UI i have issues with.. 15:36:06 I tihnk it adds a big chunk to our repository.. 15:36:07 ashimema: your point is valid 15:36:07 i already had it that way, kivilahtio_. 15:36:14 #info client side = Swagger Ui 15:36:15 which will quickly look old and take space 15:36:43 ashimema: It add a one-time chunk. and it grows if we modify it. I don't see hoe Swagger2 UI is a big chiunk considering Koha git repos is 3GB+ 15:36:43 having Swagger UI in koha only adds a self-contained "webapp" 15:36:50 could it be like git-bz? 15:36:51 personally.. our documentation page for the api should be one simple page allowing you to download the included swagger spec.. 15:36:56 something you clone extra? 15:37:17 and pointing you to a couple of tools to turn spec file into human readable interactive documentation. 15:37:22 tcohen++ 15:37:22 kivilahtio_: tI think comparing to the repo is not fair -have to think tarballs 15:37:57 ashimema: I think it could work. But how do we easily allow QA-people to work with the API? 15:38:08 ok, so i think we can note that one question is that we need to decide what to iclude in the repo and if we include Swagger UI 15:38:15 so there is another question about documentation, right? 15:38:22 QA people would be doing more than the client does anyway! 15:38:23 trying to structure this a bit 15:38:24 Right.. 15:38:26 so QA wise.. 15:38:36 I am lost, Are we talking about the 1Mo patch? 15:38:37 ashimema: I think tehre is a lot for QA people in the API 15:38:42 I expect I'll use Postman, as my favourite api inspector.. 15:38:43 first patch of bug 13799? 15:38:44 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13799 new feature, P5 - low, ---, julian.maurice, Needs Signoff , Add base for building RESTful API 15:38:51 I'd load the swagger spec.. 15:39:00 ashimema: I need to duckduckgo postman 15:39:11 please explain the process with posstman ashimema 15:39:12 and run tests agains the api using it. 15:39:25 can we better think of making kohadevbox take care of setting swagger-ui for a qa env? 15:39:50 decouple to simplify things 15:40:00 ashimema: is postman free and open source? 15:40:15 it's free.. 15:40:22 but not OS? 15:40:23 it's no longer open source :( 15:40:36 I'd liek to replace it some time when I find something equally powerful 15:40:36 ... 15:40:41 but the point is.. 15:41:00 Swagger UI doesn't give you anything beyond what a huge number of public tools out there do.. 15:41:09 i don't understand why integrating swagger ui is a problem 15:41:40 Could you just confirm me that the problem is the 1Mo patch on bug 13799? 15:41:42 ashimema: you stand correct there. But Swagger UI is Apache2 15:41:50 Joubu: yes 15:42:00 hmm:) 15:42:03 really ? :) 15:42:12 Joubu: 1MB is too much 15:42:16 :) 15:42:38 Do you want me to point you out other of patches in the QA which are > 1 Mo ? 15:42:47 (don't say yes, I don't want to find them) 15:42:50 ashimema: I think using Open Source is more important. 15:43:03 but I think that the doc of the API is important 15:43:03 and we need a easy tool for QA people to start inspecting our API 15:43:06 I think freedom to choose is more important 15:43:07 and 1Mo is nothing... 15:43:16 ashimema: you can still use wahtever you want 15:43:18 imho.. why bundle someone elses client in our app 15:43:25 and there are certainly other topics to talk about 15:43:28 especially as your literaly just embeding a point in time copy.. 15:43:49 ashimema: so could we make a wiki instructions on how to easily deploy the Swagger UI? 15:43:50 for instance, Does everybody agree with the routes? 15:43:52 how easy would it be to set up the tool if it was not bundled? 15:43:56 so we don't have to include it in Koha git? 15:43:57 does it need a lot of config? 15:44:02 or the implementation, or something else. 15:44:03 cait: not very much 15:44:11 excactly.. 15:44:20 ok i will add as idea 15:44:28 we could add instructions on how to deploy API inspection tools for our API 15:44:33 and we really need to move on alittle bit ok? we can put this on the wiki and continue on ml 15:44:47 #idea add instroctions on how to bundle Swagger UI but don't bundle it 15:44:57 I think ashimemais corerct about bundling a place-in-time copy 15:44:59 I just don't like embedding another app ad-nausiam into ours.. 15:45:14 especially since there seems to be a whole ecosystem of API inspectors out there 15:45:25 but we need good instructions for QA people to deploy the API inspector 15:45:41 antoher question was documentaton 15:45:44 having a apge say 'here's the swagger spec file, load it into your favourite client" makes much mroe sense to me.. rather than maintaining an embeded copy of another app.. 15:45:47 which is not easy for a linux-newbie 15:45:50 I think we should move the swagger-ui stuff somewhere else for now, I proposed kohadevbox already, so it is ready for QA people to test 15:45:54 can we agree to say that the swagger... spec? conf? is the documentation? 15:45:57 that you use with a tool? 15:46:00 if we also put on the same page a few links out to some popular swagger cleints.. all the better. 15:46:05 cait: yes 15:46:10 and focus on the design decisions and technicall stuff that needs to be addressed right now 15:46:11 what#s the right term? 15:46:12 ashimema: that is a good idea 15:46:29 deploying swagger ui will not be that easy, changes have be made in it for the authentication (bug 1392) 15:46:30 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1392 major, P3, ---, paul.poulain, CLOSED FIXED, Card number does not save with autoMemberNum turned on 15:46:31 #idea add a wiki page with different alternative UIs 15:46:40 13920 15:46:51 bug 13920 15:46:52 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13920 new feature, P5 - low, ---, julian.maurice, Needs Signoff , API authentication system - proposal 15:47:28 #info Swagger UI has been changed for authentication 15:47:31 ok.. other stuff then.. 15:47:40 and i don't think there are alternative UI that understand the swagger spec, but maybe i'm wrong 15:47:57 So.. am I right in thinking robin has built packages fro a point in time release of Mojolicious and Mojolicious::Plugin::Swagger2? 15:47:58 #info the documentation is in the swagger specs - can be inspected using tools 15:48:05 jajm: that is a good point 15:48:08 jajm.. 15:48:19 it is not easy to deploy it 15:48:38 lol... 15:48:41 :) 15:48:47 ok, you lost me here :) 15:48:48 but we can continue 15:48:57 I think we can just write a wiki page to do that 15:49:02 jajm: swagger-codegen, postman, httpinspector.. 15:49:05 and tcohen can set up a devbox 15:49:08 can i get a volunteer to add the ui in/out thing to the wiki as something to be worked out? 15:49:09 they all buld you a client form aswagger spec.. 15:49:22 ashimema: how about the Koha authentication? 15:49:24 ashimema, robin has backported the existing package of Mojolicious for wheezy, but created a new package for Swagger2 15:49:25 i'd rather hae another volunteer than tcohen - rms are super busy 15:49:35 ashimema: you need to tweak the tool because Koha cannot use a standard basic auth 15:49:38 that's another issue I have with this.. 15:49:38 or digest auth 15:49:51 what do you mean by.. the koha authentication. 15:49:53 is authentication a good topic to talk about next hten? 15:50:00 ashimema, ok so i was wrong :) 15:50:04 it is the next topic accoriding to the agenda 15:50:11 :) 15:50:16 we should try to organize the discussion a bit 15:50:20 yep 15:50:25 I am following :) 15:50:28 i am trying, but you guys are talking so fast :) 15:50:32 my sliht worry about mojo and it's swagger plugin is I konw how fast mojo moves.. 15:50:32 heh 15:50:42 ashimema: I don't 15:50:45 way way way faster than packages generally do. 15:50:49 ashimema: please enlighten 15:51:03 ashimema: do we need to upgrade? 15:51:17 Mojolicious is 'breaking edge'.. meaning they introduce breaking changes in releases pretty often.. 15:51:36 so we'll need to be rather carefull that we stick to certain versions of it and it's plugin.. 15:51:53 that shouldn't be hard to do 15:51:54 ashimema: we rely on Jessie's Mojoliciousm so we expect to be able to keep the version for a while 15:51:56 just a maintanence thing.. i'm not voicing it as a bad thing (I have mojo apps here and love them).. 15:52:00 ashimema: point taken. So far we use Mojolicious because of the Swagger plugin 15:52:13 but for packages we'll need to be careful when debian upstream brings in a new mojo for example.. 15:52:14 and other issues 15:52:19 as it's liveky to break our api 15:52:29 coolios.. 15:52:34 in which case that's a non point :) 15:52:34 ashimema: the api is done 95% bu the Swagger-plugin 15:52:35 great 15:52:48 auth.. 15:52:55 check it out :) 15:53:04 someone explain to me the koha authentication stuff you've built into it.. 15:53:06 Bug 13920 - 9. API authentication system - Swagtenticator authentication - WIP 15:53:07 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13920 new feature, P5 - low, ---, julian.maurice, Needs Signoff , API authentication system - proposal 15:53:08 #info Mojolicious is moving fact, need to keep an eye on new versions 15:53:09 I've not had a chance to read it yet.. 15:53:18 read the commit message 15:53:25 authentication 15:53:26 Koha permission driven by the swagger specification 15:53:33 can we get a quick summary about hwo it works, jajm? 15:53:39 so you dont need to put anything related to authentication in the Controllers 15:53:46 or kivilahtio_? 15:53:47 i heard kivilahtio_ was going on a holiday this saturday so... 15:53:50 cait: we have two versions 15:54:05 I can explain 15:54:20 (am here, bit late to introduce myself but hi) 15:54:52 First version /jajm) uses a Mojolicous route to authenticate user with the API-key, then permissions are checked in each Controllers action_handler seaprately, without touching Swagger at all 15:55:19 OK.. agree I don't like that.. 15:55:26 auth should be handled before the controller 15:55:33 in the router as such 15:55:36 my version authenticates in the swagger-plugin. Permissions required are defined in the swagger.json and server implementator doesnt need to touch the authentication anyway 15:55:39 go on kivi 15:55:45 #info 2 versions for authentication rightnow 15:56:07 also permission for each route and action are definend in the Swagger2 definitions and are used by Koha to authenticate the user. So we dont need to document and implemetn permissions in separate places 15:56:08 jajm - do you agree with the description? 15:56:09 ashimema, auth is handled before the controller in the first version, but doesn't check for Koha permissions 15:56:41 I wonder... do we need mroe specific permissions than koha has? 15:56:44 see the commit message here for better explanation and examples 15:56:45 http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=40592 15:56:46 be able to read a borrower but not update? 15:56:48 or similar 15:56:54 cait: it is inlcued 15:57:22 swagger.json allows setting different permissions for reeading (GET) and updateing (POS) and inserting (PUT) a borrower 15:57:44 hmmm.. 15:57:49 how do i give someone access to the api? 15:57:50 I'm sort of seeing where your going with it.. 15:57:52 or my version of it allows, this is not a Swagger spcification standard but an allowed extension to it 15:58:09 so we get behaviour from documentation 15:58:19 thus, we only update documentation and we get updated behaviour as well 15:58:28 no need to define the same thing in 5 places like with Zebra indexes 15:58:32 can you still work with permissions from within a controller though.. 15:58:38 yues you can 15:58:44 k 15:58:45 #chair tcohen 15:58:45 Current chairs: cait tcohen 15:58:49 but no in the Swagger2 context, because that context is never given to the Controller 15:58:54 #chair ashimema 15:58:54 Current chairs: ashimema cait tcohen 15:59:03 please add #infos where you see fit 15:59:37 I think my feature is superior to anything I have ever made, but there is a disadvantage, where the Swagger2-plugin is subclassed by my KohaliciousSwagtenticator 15:59:56 the subclassing is quite extensive, because of the way the Swagger2-plugin is implemeted 16:00:14 I already emailed the author to make some modifications to make it more extendable 16:00:23 but I doubt we will get help from him 16:00:30 he's a nice bloke.. 16:00:34 ;) 16:00:57 I guess he would be nicer if money was involved instead of just good will 16:01:00 kivilahtio_, he has been very helpful for me ;) 16:01:07 jajm: I try :) 16:01:11 I promised in the HAckFest 16:01:30 and I need to get this things sorted out. So I can start working on Serails improvement our Serials department really must have ASAP 16:01:33 verdict is out on authorization in sepc for me I'm afraid.. 16:01:40 still mulling it over in my head 16:02:09 but I don't see it as a blocker 16:02:16 If we use Swagger, we should embrace it. Getting documentation and behaviour in one place is a huge benefit in telling others how to use our api 16:02:27 and w edon't "just forget" some things 16:03:27 so does your system throw meaningful errors when someone attempts to hit a route they don't have the right priviledges fro? 16:03:30 so does your system throw meaningful errors when someone attempts to hit a route they don't have the right priviledges for? 16:03:55 ashimema: yes, and it tells which permission they need. Pending they succeed at the API key authentication first 16:04:09 ok.. 16:04:18 that is why I didBuugg 14437 - Refactor C4::Auth::haspermission() to Koha::Object and return better 16:04:18 errors. 16:04:19 I need to shoot off in a tic.. 16:04:24 but that's sounds promising 16:04:29 It is aweeeesome 16:04:39 authentication wise.. I think we need to also enusre we can handle some other forms.. 16:04:44 it is just a "tad" hard to maintain when upgrading Mojolicious and Swagger2-plugin 16:04:47 i am very sorry i have to go :( 16:04:48 I need to read into this API-Key stuff.. 16:05:01 feels like we're re-inventing OAuth 16:05:08 ashimema: me too, this is not my strong point. And we should look into OAuth2.0 and just basic api_key authentication 16:05:19 tcohen will take over I hope - chairs are set 16:05:26 no worries cait 16:05:28 I am just refactoring jmjm's authentication system to work better with Swagger2 16:05:32 OK.. for a 'nice' user experience with api development we should 16:05:43 please be good and have some great ideas/plans :) 16:05:46 use http basic auth (over https of course) 16:05:51 ashimema: also, my feature is easily extendable to support other types of authentiocations 16:05:52 this allows querying the API via curl 16:06:09 and action items to move things forward :) 16:06:22 ashimema: well not easily extendable, but you see that each authentication type is encapsulatedin it's own subroutine, so just add them and mix 16:06:23 authentication and authorization should definitely be in two completely separate pieces of code 16:06:39 ashimema: they are 16:06:46 again.. withou hving read the code i can't comment 16:06:47 great.. 16:06:50 so.. 16:06:52 but under the sigular check in the swagger2-plugin extension 16:06:53 for me.. 16:07:28 ashimema: do you think you could have a look at the code soon? 16:07:30 I want' Basic auth for api discoverability.. cookie inspection (for binding the the same cookie as we currently give out) and any tohers are nice extra's 16:07:37 but those two are my first priorities 16:07:44 yup 16:07:45 hopefulyl Joubu.. 16:07:51 but could we still push this to master without those? 16:07:54 up to my ears at the minute as usual.. but this is important 16:08:01 you seem to have strong opinion on the code 16:08:01 ashimema: I agree 16:08:05 but the dev is already done 16:08:06 I think the cookie one is super important.. 16:08:13 ashimema, cookie ? 16:08:14 so if you have think to say... ;) 16:08:25 without it we can't use the api calls natively in koha 16:08:28 only for external apps 16:08:40 jajm: so we can hook angular to be more specific :-D 16:08:45 ashimema: Look like I have to implement that, because I need this from Koha :) 16:08:49 exactly :) 16:08:57 agreed 16:09:10 what does hooking angular has to do with this? 16:09:22 also.. are we using mojo sessions calls anywhere? 16:09:27 ashimema: nope 16:09:31 if we are we're creating duplicate user cookies.. 16:09:33 great.. 16:09:36 tick 16:09:39 angular + rest = good 16:09:46 i feel that cookie and rest api should not appear in the same phrases... 16:09:59 -s 16:10:06 jajm: I was hoping to use the REST API to augment existing Koha features 16:10:17 kivi++ 16:10:18 thus we need to share the cookie-authentication 16:10:19 myself as well 16:10:19 exactly 16:10:39 ashimema: why we should use Mojo::Session calls? 16:10:46 jajm.. I know exactly where your coming from.. 16:10:55 we shouldn't use Mojo::Session calls ;) 16:11:00 jajm: think search results, updating holdability of items on the resultset, using ajax to make rendering faster 16:11:01 I could easily add existing authentication mechanisms from C4::Auth to the Swagtenticator? 16:11:06 though that's more of a personal thought.. 16:11:23 Mojo::Sessions bascialyl create a session cookie.. 16:11:42 to be properly restul we don't want a session cookie.. just an auth 16:11:43 ashimema: so we should use the Koha CGISESSID instead 16:11:50 yes.. 16:11:53 I beleive so.. 16:11:59 or eventally move to Mojo::Session.. 16:12:00 but we need the CGISESSID as well to work with Koha 16:12:16 but not have both as they'll get confusing fast having two cookies that in effect handle the same information ;) 16:12:23 I can add the CGISESSID tomorrow to the Swagtenticator 16:12:35 all we want to use the koha CGISESSID cookie for is authentication. 16:12:38 this will help me a lot as well in testing :) 16:12:43 jajm.. that's what makes it restfull. 16:12:55 we *need* to reuse CGISESSID if we were to use the RESTful api from Koha's UI 16:13:14 restfull means you send all you need with every request to get a response.. including Authentication.. 16:13:18 but somebody should take another look at the propsed authentication system 16:13:23 I mean the api-key system 16:13:38 and how does REST do auth? 16:13:47 so.. if we have a auth fallback system.. username:password in the url will work.. or the cookie will work.. or an OAuth token will work. 16:13:50 you need to hae the api-key/signature there as well 16:13:56 in effect they're all jsut mediums for the same data.. 16:13:59 a signatrue saying.. 16:14:01 it'#s me 16:14:26 kivilahtio_: The API-key system looks good, but why the list of API keys on the OPAC? 16:14:27 ashimema: could you make a document on how you think the Koha API should authenticate, in addition to the GCISESSID 16:14:37 pianohacker: ask jmjm 16:14:42 pianohacker: ask jajm 16:14:51 right.. 16:14:54 i really need to had off.. 16:15:00 pianohacker, each user should be able to create api keys, don't they ? 16:15:05 we know you don't want to :) 16:15:06 I'll read the minutes when I get back and make any notes on he wiki. 16:15:15 sorry chaps.. daughter is waiting at school for pickup ;) 16:15:16 ashimema: PM me! 16:15:23 ashimema: fiorst things first. thanks for feedback 16:15:40 jajm.. 16:15:43 jajm: general public users? 16:15:51 a user should just use their credentials to login.. 16:15:52 pianohacker: any registered Koha user 16:15:57 jajm: creating an API key works for using the API explicitly, but what about using it from the UI? 16:15:58 no need for a seperate api key 16:16:00 ashimema: go get your daughter 16:16:04 in the form of AJAX calls? 16:16:12 bye 16:16:15 brb 16:16:15 bye! 16:16:54 I think jajm's idea that every registered borrower can get their own API keys is superb 16:17:01 this seems like something that has a lot of potential to confuse the general public. And aren't API keys only really useful for entities completely outside of Koha? 16:17:10 we just limit what they can do with Koha borrower permissions 16:17:47 pianohacker: that is true as well, we could have a borrowercategory "AUTOMAT" which get this API view displayed 16:17:53 if each borrower can create their own API keys, then the API keys are pointless, no? 16:17:54 but then again 16:18:02 I see no harm in presenting the view to everybody 16:18:04 as the borrower can just authenticate normally 16:18:21 pianohacker: he can use his key like a ssh-key to more easily authenticate 16:18:41 pianohacker: or maybe one of our patrons wants to make a mobile phone app to use our library? 16:18:53 as ashimema is a plus, but the basic authentication mechanisms are mandatory to be implemented for the feature to be useful 16:18:55 pianohacker, some borrowers could be interested in using this api outside of the opac 16:19:00 pianohacker: giving the keys out publicly is a great idea and just another way of authenticating 16:19:18 tcohen: I will implement the CGISESSID tomorrow 16:19:27 or this week, this is a top riority for me 16:19:28 s/is/ said, is/ 16:19:39 true, but that raises a very tricky point 16:19:40 kivilahtio_: great 16:19:41 I just need confirmation that the Swagtenticator is a good idea 16:19:50 so I wont spend another 3 days for nothing :) 16:20:01 maybe we could rename it :-D 16:20:04 hahaha 16:20:06 i mean, i use google docs and google docs make some ajax calls for me, but sometimes i want to do something more, and this is possible because google give me access to the api 16:20:17 I have a sound reasoning for the name :) 16:20:24 someone developing a mobile app like you mentioned might want to allow patrons to log into their accounts within that app, right? 16:20:33 check fines, checkouts, etc etc 16:20:42 Could it be possible to have a wiki page (or whatever!) as an overview of 1/ what is done 2/ what should be done 3/ what should be modified (why)? Written by the different authors of this discussion 16:21:11 I have some post-its lying around :) 16:21:37 tcohen: would it make you happy if I renamed it? 16:21:48 if the borrower in question can just generate an API key, there's no way the library can revoke access to the app for bad behavior 16:21:55 Koha::Rest::V1::Plugins::TomasCohenAutenticator 16:22:07 :-P 16:22:28 pianohacker, this is a good point 16:22:40 pianohacker: if the account is debarred, then no API keys 16:23:06 pianohacker: the API key is just a substitute for the CGISESSID-authentication. all same borrower restirctions apply. Tehre is a permission handling mechanisms here 16:23:16 i'd say that the use case the api-key mechanism is interesting, with some edge cases that might be tricky 16:23:39 well, yes, but your ability to check out books shouldn't necessarily be linked to your possibly being a bad API customer :) 16:23:52 pianohacker: good point 16:23:54 regardless, though, kivilahtio_, I like swagtenticator, it seems like the cleaner option 16:23:55 i need to leave for a meeting 16:24:00 kivilahtio_: can u chair 16:24:01 pianohacker: bless you 16:24:09 tcohen: I have absolutely no idea how to 16:24:25 #chair kivilahtio_ 16:24:25 Current chairs: ashimema cait kivilahtio_ tcohen 16:24:32 but I think we could make a document about issues 16:24:38 and see what we need and where to go 16:24:43 bye 16:24:54 so, actions? 16:25:03 I think 13799 can be pushed to master, but not recommended for production use 16:25:22 the other related bugs are not so functional and lack authentication 16:25:29 there are some bigger issues there 16:25:43 what about ashimema's suggestion to strip swagger-ui out? 16:25:44 I think you are the one :) 16:25:55 mainly Authentication is critical to make any other features 16:26:07 bbl 16:26:17 tcohen: I think it is a solid point, but we should provide easy way for QA peeps to test the API 16:26:51 so lets pull out Swagger UI nad add wiki pages for instructions 16:27:14 tcohen, i think we can remove swaggerui for now, if it really blocks the integration, but it would be really useful for testing 16:27:23 #vote Pull Swagger UI out and create a wiki-page for instructions on how to deploy various API inspectors. 16:27:28 #yes 16:27:57 who? :) 16:28:01 no idea 16:28:10 it is many months since i did this 16:28:13 a wiki page ? or a separate bug ? 16:28:25 jajm: hmmm, a separate bug might be better 16:28:38 jajm: but dont we have already a ton of separate bugs? 16:28:45 can i cancel this vote? 16:28:53 #endvote 16:29:07 #vote Pull Swagger UI out and create a bug for instructions on how to deploy various API inspectors. 16:29:08 better? 16:29:09 i think better is "take cover." :) 16:29:18 #yes kivilahtio 16:29:19 little separate bugs are better than big bug imo 16:29:21 #kivilahtio, yes 16:29:45 jajm: I think we wont have so many instructions 16:29:56 jajm: we have instructions for Swagger2 UI and maybe postman 16:30:05 they all fot there nicesly as separate commits 16:30:10 kivilahtio_: I think a vote is not needed 16:30:18 Joubu: I didn't want to chair :) 16:30:22 we need actions for the next steps 16:30:29 #endvote 16:30:32 i can split bug 13799 16:30:33 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13799 new feature, P5 - low, ---, julian.maurice, Needs Signoff , Add base for building RESTful API 16:30:39 jajm: ok 16:30:53 I need to add Nginx and Hypnotoad as a bug 16:31:16 kivilahtio_, the bug is already created 16:31:24 you did it for me? 16:31:27 that is nice :) 16:31:38 bug 14448n 16:31:38 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14448 enhancement, P5 - low, ---, koha-bugs, NEW , Hypnotoad and Nginx config for REST API 16:31:40 I reiterate my wish: I really would like more communication and have a better visibility on what is going on. Who is working on what, what is done, what should be changed, etc. 16:31:41 bug 14448 16:31:43 with the bug numbers 16:31:50 I cannot do it 16:32:11 and I think several people should do it, collaborate, you know? 16:32:54 Joubu: to facilitate better visibility we need a better project manangement tool than Bugzilla 16:33:14 let's start with mail and a wiki page... 16:33:19 Joubu: I can recommend Redmine, I just dpeloyed a redmine installation to serve the Finnish Koha-community 16:33:44 a wiki page seems good :) 16:34:05 we already have 4 peeps working on Koha, doing migrations and testing stuff 16:34:08 it's cool :) 16:34:25 4 technicals 16:34:39 or maybe a google doc? 16:34:42 kivilahtio_, jajm: are you willing to start it ? 16:34:42 anywayu 16:34:47 I can start it 16:34:49 with maybe ashimema 16:35:05 thanks 16:35:06 I have a lot of ideas and I think I have a quite a clear vision of what is happening 16:35:34 #action kivilahtio_ will initiate a wiki page as an overview of the REST work 16:35:37 something like that 16:35:42 #yes 16:35:49 #vite, yes :) 16:35:54 #vote, yes :) 16:36:17 who want to stay informed? 16:36:23 And I think you can end the meeting 16:36:28 #endmeeting