2007-09-05T01:31:18 <ThomasWaldmann> http://hg.moinmo.in/moin/1.6/rev/47d229ad5e56 action=info must be usable on deleted pages
2007-09-05T02:16:07 <CIA-27> moin: Ville-Pekka Vainio <vpivaini AT cs DOT helsinki DOT fi> * 3101:15b49f2374f1 1.7-maninfo-vpv/MoinMoin/script/import/manimport.py: Add UriException to be handled for XML parsing
2007-09-05T02:16:10 <CIA-27> moin: Ville-Pekka Vainio <vpivaini AT cs DOT helsinki DOT fi> * 3104:725dce686be9 1.7-maninfo-vpv/MoinMoin/ (action/info.py stats/hitcounts.py): merge from main
2007-09-05T07:29:10 <grzywacz> moin
2007-09-05T08:23:08 <ThomasWaldmann> moin
2007-09-05T09:45:27 <dreimark> moin
2007-09-05T12:33:28 <ThomasWaldmann> moin
2007-09-05T12:36:46 <ThomasWaldmann> dreimark: can you explain http://hg.moinmo.in/moin/1.6/rev/47d229ad5e56 ?
2007-09-05T12:52:35 <xorAxAx> ThomasWaldmann: do you know gsoc.tlarsen@gmail.com?
2007-09-05T12:52:48 <xorAxAx> he has admin perms on the google code project for soc
2007-09-05T12:54:28 <ThomasWaldmann> no. why do you ask?
2007-09-05T12:55:25 <xorAxAx> because unknown people with admin permissions are not good
2007-09-05T12:55:52 <xorAxAx> hmm, i cant edit the google code wiki - it always bails out with "update collision"
2007-09-05T12:56:27 <dreimark> ThomasWaldmann: buf fix for http://moinmoin.wikiwikiweb.de/MoinMoinBugs/HitCounts
2007-09-05T12:56:53 <dreimark> and a not reportet bug if one tried to enter a not existing page with ?action=info&hitcounts=1
2007-09-05T12:57:03 <dreimark> that has caused the same traceback
2007-09-05T12:57:38 <ThomasWaldmann> dreimark: you need to invoke info action for deleted pages, e.g. to revert to an older rev
2007-09-05T12:58:21 <ThomasWaldmann> the first part of your cs makes that impossible
2007-09-05T12:59:23 <dreimark> ThomasWaldmann: ok, then I need a check for deleted pages too
2007-09-05T12:59:32 <ThomasWaldmann> no
2007-09-05T12:59:42 <ThomasWaldmann> you need to fix it at the right place
2007-09-05T12:59:42 <dreimark> why not
2007-09-05T12:59:44 * xorAxAx updated http://code.google.com/p/google-summer-of-code-2007-moin/
2007-09-05T12:59:55 <dreimark> which is?
2007-09-05T13:00:48 <ThomasWaldmann> where the problem you try to fix happens
2007-09-05T13:00:49 <dreimark> who is gsoc.tlarsen ?
2007-09-05T13:01:24 <ThomasWaldmann> dreimark: ok, let's talk about the second part of the cs - what does your code do there?
2007-09-05T13:01:27 <xorAxAx> dreimark: i assume that he is a technician
2007-09-05T13:02:04 <dreimark> ThomasWaldmann: it changes the name of the page to the name how it is stored in the log file
2007-09-05T13:03:05 <ThomasWaldmann> that XXX bug comment, did you verify if it is correct still?
2007-09-05T13:04:08 <ThomasWaldmann> and why do you quote eventpage instead of unqouting filterpage once?
2007-09-05T13:04:25 <dreimark> ThomasWaldmann: I missed to remove that line it is fixed with that change.
2007-09-05T13:04:39 <ThomasWaldmann> no it is not
2007-09-05T13:04:54 <dreimark> ThomasWaldmann: why not
2007-09-05T13:05:14 <ThomasWaldmann> if eventpage is quoted representation and you quote it again, it gets double quoted
2007-09-05T13:06:18 <ThomasWaldmann> so i suggest you completely revert that changeset for starting and then do more investigations before fixing it again
2007-09-05T13:07:04 <ThomasWaldmann> if you are working on it anyway, try to fix that XXX comment (or remove it, if it is untrue meanwhile)
2007-09-05T13:07:54 <dreimark> ThomasWaldmann: you do want stored it unquoted in the log file ?
2007-09-05T13:08:10 <ThomasWaldmann> we dont change storage
2007-09-05T13:08:50 <ThomasWaldmann> but the stuff is processed in the eventlog class already
2007-09-05T13:09:04 <dreimark> why should event[2].get('pagename') -> you'Aktuelle%C4nderungen' 8( then be changed
2007-09-05T13:09:25 <ThomasWaldmann> because it is unquoted in eventlog class
2007-09-05T13:09:43 <ThomasWaldmann> at least it SHOULD be unquoted there
2007-09-05T13:10:43 <ThomasWaldmann> we try to unquote early and work internally with unicode
2007-09-05T13:11:19 <ThomasWaldmann> what did expand u to you???
2007-09-05T13:14:23 <dreimark> ThomasWaldmann: sorry for that mistake, there was not test failing and I did not thought on the change for restoring the page
2007-09-05T13:14:30 <dreimark> which of cours is now broken
2007-09-05T13:18:57 <CIA-27> moin: Reimar Bauer <rb.proj AT googlemail DOT com> * 2798:473826ac22a4 1.7/MoinMoin/ (action/info.py stats/hitcounts.py): reverted to 2795:f24afde03048, because breaks reverting
2007-09-05T13:21:54 <CIA-27> moin: Reimar Bauer <rb.proj AT googlemail DOT com> * 2149:eecf400444dc 1.6/MoinMoin/ (action/info.py stats/hitcounts.py): reverted to 2146:6c23b608e505, because breaks reverting
2007-09-05T13:27:09 <ThomasWaldmann> dreimark: btw, by your xmlrpc putpage changes, you opened it to everyone and there is no means to switch it off except by removing write rights also for the web based page editor
2007-09-05T13:27:33 <dreimark> ThomasWaldmann: mergeDiff has the same right
2007-09-05T13:28:40 <dreimark> I would prefer a global cfg var enable_xmlrpc = False
2007-09-05T13:28:51 <xorAxAx> this is pretty much isomorphic to the normal http handling, i dont see a reason to strictly disallow xmlrpc modifications - of course that feature could be added optionaly
2007-09-05T13:29:52 <dreimark> I think on more global vars, enable_email = False
2007-09-05T13:31:20 <ThomasWaldmann> well, enable_xmlrpc might be a solution. otoh, usually wiki admins don't have a problem with someone reading the content, but they would have one with someone doing a global write to all their content.
2007-09-05T13:31:43 <dreimark> ThomasWaldmann: with mergeDiff someone could purge easily all pages
2007-09-05T13:31:56 <ThomasWaldmann> of course this is also possible by the web ui, but scripting would make it easier to do more damage more easily.
2007-09-05T13:33:02 <dreimark> we could flag more dangerous operations similiar to the xss mimetypes we try to exclude
2007-09-05T13:35:27 <dreimark> ThomasWaldmann: xorAxAx: I am not sure if I want all my wikis synchronisable
2007-09-05T13:36:02 <xorAxAx> dreimark: XSS is a direct thread, this issue isnt
2007-09-05T13:36:10 <xorAxAx> s/ead/eat/
2007-09-05T13:36:24 <dreimark> if one syncs you can get a high load
2007-09-05T13:36:32 <xorAxAx> XSS steals data/identity, this one only does valid ops
2007-09-05T13:37:05 <dreimark> xorAxAx: sure xmlrpc is a valid op
2007-09-05T13:37:15 <ThomasWaldmann> i guess some of our users would be pissed if some 4 lines script would just spam all their pages.
2007-09-05T13:37:38 <dreimark> but during configuration for example you don't want all features enabled while you set up acls
2007-09-05T13:37:42 <xorAxAx> ThomasWaldmann: ...
2007-09-05T13:37:57 <xorAxAx> as i said, optional disabling is fine
2007-09-05T13:38:07 <xorAxAx> but compared to XSS, this a really minor threat
2007-09-05T13:39:01 <ThomasWaldmann> how about disabling by default
2007-09-05T13:39:42 <xorAxAx> IMHO it shouldnt be disabled
2007-09-05T13:39:47 <dreimark> ThomasWaldmann: ok, but do we want destinguish between reading and writing or only enable_xmlrpc = False
2007-09-05T13:39:48 <ThomasWaldmann> enabling r access, but disabling w access
2007-09-05T13:39:59 <xorAxAx> because its pointless
2007-09-05T13:40:06 <xorAxAx> i could rewrite wikisync to use POST
2007-09-05T13:40:11 <dreimark> enable_xmlrpc_write = False
2007-09-05T13:40:14 <xorAxAx> and would have the same effect
2007-09-05T13:40:31 <xorAxAx> but i would agree to require a logged in user for xmlrpc ops
2007-09-05T13:40:39 <xorAxAx> (Known)
2007-09-05T13:41:44 <dreimark> xorAxAx: I do prefer users have to enable in theire configuration what all they want to use
2007-09-05T13:41:50 <ThomasWaldmann> i think it should obey normal read/write acls, except that 2 global switches
2007-09-05T13:42:04 <xorAxAx> dreimark: i dont
2007-09-05T13:42:17 <xorAxAx> ThomasWaldmann: i still think that this is bonkers
2007-09-05T13:42:25 <dreimark> phone call
2007-09-05T13:42:32 <xorAxAx> dreimark: then why write access doesnt need to be enabled?
2007-09-05T13:42:41 <xorAxAx> its a wiki, not a CMS with an editors group - by default
2007-09-05T13:43:42 <ThomasWaldmann> the question is how easy we want to make abuse possible
2007-09-05T13:44:54 <ThomasWaldmann> and the web ui has some means to counter abuse: antispam and surge prot.
2007-09-05T13:45:00 <xorAxAx> maybe you dont know how the spamming business works
2007-09-05T13:45:22 <xorAxAx> they sell programs that implement a nice API on the POST requests of webapps
2007-09-05T13:45:28 <ThomasWaldmann> also, it is obvious to wiki owner that edits via web IF are possible
2007-09-05T13:45:41 <xorAxAx> and build a spammer on top of that - the easeness of an api doesnt defeat spammers etc.
2007-09-05T13:45:48 <ThomasWaldmann> a open-by-default xmlrpc writer is non-obvious
2007-09-05T13:46:00 <xorAxAx> thats a good point
2007-09-05T13:46:46 <ThomasWaldmann> i know how they work
2007-09-05T13:47:15 <ThomasWaldmann> but I am also sure they could modify a 5 line sample script to target all MoinMoinWikis globally
2007-09-05T13:47:33 <xorAxAx> they dont need xmlrpc for that :)
2007-09-05T13:48:10 <ThomasWaldmann> there's no surge prot for xmlrpc
2007-09-05T13:48:55 <xorAxAx> then it should be added
2007-09-05T13:49:11 <ThomasWaldmann> that makes no sense
2007-09-05T13:49:19 <xorAxAx> why?
2007-09-05T13:49:54 <ThomasWaldmann> because it tries to allow human access patterns and defeat bots
2007-09-05T13:49:59 <ThomasWaldmann> xmlrpc is bot
2007-09-05T13:50:51 <xorAxAx> ???
2007-09-05T13:51:00 <xorAxAx> the primary goal is to avoid high system load, right?
2007-09-05T13:51:31 <ThomasWaldmann> and abuse
2007-09-05T13:51:47 <xorAxAx> abuse?
2007-09-05T13:52:34 <dreimark> abuse should not too easy
2007-09-05T13:53:12 <ThomasWaldmann> if some dumb bot tries to GET/POST edit all pages, it will run into SP - except if it tries slowly.
2007-09-05T13:54:27 <ThomasWaldmann> it's not perfect, but it avoids some bad things happening
2007-09-05T13:55:13 <xorAxAx> ThomasWaldmann: now you are talking about bots again
2007-09-05T13:55:29 <xorAxAx> so you mean spiders
2007-09-05T13:55:42 <xorAxAx> those could use xmlrpc as well - then why is there no surge protection?
2007-09-05T13:56:07 <ThomasWaldmann> because xmlrpc is not driven by a human, but by a script
2007-09-05T13:56:30 <ThomasWaldmann> so there is no point in assuming human access patterns as there wont be any
2007-09-05T13:56:38 <xorAxAx> a spider is neither driven by a human
2007-09-05T13:57:00 <xorAxAx> a GET spider is as much driven by a human as a XMLRPC spider
2007-09-05T13:57:58 <ThomasWaldmann> if a GET spider is acting too fast, it is badly implemented and I don't care if it is locked out.
2007-09-05T13:58:23 <xorAxAx> yes, the same is true for an xmlrpc script
2007-09-05T13:58:32 <ThomasWaldmann> but for valid xmlrpc usage, you maybe dont want to rate limit access
2007-09-05T13:58:40 <xorAxAx> i dont see any difference
2007-09-05T13:59:23 <ThomasWaldmann> spiders have time and should be low impact
2007-09-05T13:59:49 <ThomasWaldmann> if you are going to a train and want to sync your company wiki to your notebook, you dont have time
2007-09-05T14:00:08 <xorAxAx> now you are projecting certain use cases to the protocol
2007-09-05T14:00:29 <xorAxAx> i have already written an xmlrpc-based spider, to get snapshots from moinmaster
2007-09-05T14:00:30 <ThomasWaldmann> surge protection is all about use cases
2007-09-05T14:01:02 <xorAxAx> i dont think that wikisync will trigger surge protection because it is badging rpc calls
2007-09-05T14:01:10 <xorAxAx> and blocks on completed badges
2007-09-05T14:01:24 <johill> xorAxAx: you mean batch ;)
2007-09-05T14:01:25 <xorAxAx> s/badg/batch/
2007-09-05T14:01:34 <xorAxAx> johill: :-p
2007-09-05T14:01:36 <johill> heh :)
2007-09-05T14:01:36 <ThomasWaldmann> it wont trigger sp because xmlrpc is excluded from sp
2007-09-05T14:01:50 <xorAxAx> ThomasWaldmann: i was talking about the issue you presented above
2007-09-05T14:03:14 <ThomasWaldmann> ok, someone else could batch calls also
2007-09-05T14:03:14 <johill> surge protection always triggers when I edit my wiki :/
2007-09-05T14:03:33 <ThomasWaldmann> johill: then your cfg mismatches your speed :)
2007-09-05T14:03:42 <johill> yeah, I'm faster than the default config :P
2007-09-05T14:04:55 <johill> seriously though, xmlrpc has lower overhead too, no?
2007-09-05T14:05:15 <johill> or can you fetch rendered pages too?
2007-09-05T14:05:37 <ThomasWaldmann> anyway. IMHO that xmlrpc stuff can't stay how it is right now. there should be no non-obvious open door with such a high impact, thus there should be at least a global switch for xmlrpc write's to the wiki and the default should be off (like in 1.5).
2007-09-05T14:06:02 <johill> especially since you only need the user ID...
2007-09-05T14:06:52 <ThomasWaldmann> johill: you can fetch rendered pages
2007-09-05T14:07:44 <dreimark> I do want a global flag too but not one which only works for putPage
2007-09-05T14:07:45 <johill> ok. somehow I thought you couldn't
2007-09-05T14:08:15 <ThomasWaldmann> dreimark: yeah
2007-09-05T14:08:27 <johill> I want a flag to just turn off xmlrpc completely too, I don't think I ever need it so even if "it doesn't hurt" it still could have security bugs that wouldn't affect me then
2007-09-05T14:09:45 <ThomasWaldmann> btw, we have actions_excluded so we could just use this for the case someone wants to exclude xmlrpc(2) action completely
2007-09-05T14:10:20 <dreimark> a wiki admin should enable it if he like to use it and he should know what he is doing
2007-09-05T14:10:36 <ThomasWaldmann> so we just need 1 cfg variable for the write enabling stuff
2007-09-05T14:11:24 <johill> ThomasWaldmann: oh good point (re actions) but does it currently work that way? I thought xmlrpc was short-circuited really early
2007-09-05T14:11:45 <ThomasWaldmann> that needs to be reviewed and changed then :)
2007-09-05T14:11:56 <johill> not sure anyway
2007-09-05T14:12:13 <ThomasWaldmann> (it will still be special, but include that check for actions_excluded)
2007-09-05T14:13:20 <johill> I think it actually does that check before invoking it
2007-09-05T14:13:22 * johill looks
2007-09-05T14:13:39 <dreimark> meeting
2007-09-05T14:13:40 <johill> btw
2007-09-05T14:13:54 <johill> how will surge protection work when AttachFile,get can't be special any more?
2007-09-05T14:14:49 <ThomasWaldmann> different :D
2007-09-05T14:14:52 <johill> ok, looks like the special handling of xmlrpc doesn't extend to getAvailableActions
2007-09-05T14:15:06 <johill> hence, it should be possible to block it, the default should probably just exclude it then
2007-09-05T14:16:35 <ThomasWaldmann> then the default would change from 1.5 (1.5 allowed xmlrpc, but not putpage, by default)
2007-09-05T14:21:03 <johill> oh
2007-09-05T14:21:20 <johill> well, that's ok though
2007-09-05T14:21:36 <johill> if people actually used xmlrpc they'll rapidly notice the error. hopefully they read CHANGES too
2007-09-05T14:22:57 <ThomasWaldmann> we can change that, yeah, I just wanted to note :)
2007-09-05T14:40:28 <ThomasWaldmann> dreimark: btw, your commit comment is misleading
2007-09-05T14:41:14 <ThomasWaldmann> you didn't "revert to <revision_before>", but you "reverted <wrong_changeset>"
2007-09-05T14:41:54 <ThomasWaldmann> that is a big difference in case there were other changesets after the one you reverted
2007-09-05T14:45:35 <ThomasWaldmann> what do we do for the case 'xmlrpc' in actions_excluded for an incoming xmlrpc request?
2007-09-05T14:47:04 <johill> return 403?
2007-09-05T14:47:10 <johill> or 405 maybe
2007-09-05T14:47:21 <johill> no wait, method is different
2007-09-05T14:49:40 <dreimark> ThomasWaldmann: ok, next time I do it better
2007-09-05T14:51:37 <ThomasWaldmann> johill: or xmlrpclib.Fault()?
2007-09-05T14:52:53 <johill> ThomasWaldmann: I would expect that the remote side is able to handle 403 properly
2007-09-05T14:55:27 <ThomasWaldmann> xorAxAx: what's your opinion, 403 or xmlrpclib.Fault() in case we don't support xmlrpc calls?
2007-09-05T14:57:06 <xorAxAx> a fault
2007-09-05T14:58:57 <johill> why?
2007-09-05T14:59:12 <johill> 403 is what we do for everything else too
2007-09-05T15:00:38 <johill> iow, why special-case xmlrpc?
2007-09-05T15:01:58 <xorAxAx> because xmlrpc is not very rest-affine in certain environments :)
2007-09-05T15:02:09 <xorAxAx> i am assuming that a fault eases debugging
2007-09-05T15:02:15 <johill> -ETOOMANYBUZZWORDS
2007-09-05T15:02:17 <johill> rest-affine?
2007-09-05T15:02:26 <xorAxAx> dont you know REST? :)
2007-09-05T15:02:40 <xorAxAx> no idea what it means, i have a distant feeling that it fits into that sentence, though
2007-09-05T15:03:30 <johill> I know restructured text (ResT) and ReST (representational state transfer)
2007-09-05T15:03:37 <ThomasWaldmann> ok, fault could be better to wrap some meaningful msg like "xmlrpc action disabled on this server"
2007-09-05T15:03:38 <xorAxAx> the latter
2007-09-05T15:03:54 <xorAxAx> ThomasWaldmann: a 403 can wrap error messages as well in the HTTP response header
2007-09-05T15:04:01 <xorAxAx> the question is which eases debugging
2007-09-05T15:04:16 <ThomasWaldmann> the question is whether you will see them somewhere
2007-09-05T15:04:29 <johill> well a good xmlrpc implementation should raise an error in both cases
2007-09-05T15:04:45 <johill> it practically has to
2007-09-05T15:05:18 <johill> xorAxAx: btw, rest is about using different URIs for different methods, not something we do now, do we?
2007-09-05T15:05:30 <xorAxAx> johill: no, not only about that :)
2007-09-05T15:05:43 <xorAxAx> thats the nice thing about buzzwords, you are always right
2007-09-05T15:06:22 <johill> in any case, xmlrpc is not rest
2007-09-05T15:06:34 <johill> even with the fuzzword issue
2007-09-05T15:06:59 <xorAxAx> exactly
2007-09-05T15:07:04 <xorAxAx> thats what i said
2007-09-05T15:08:04 <johill> oh so you're saying we should avoid using HTTP to transfer the error because xmlrpc ... ugh
2007-09-05T15:08:09 <johill> that's dumb, imho
2007-09-05T15:08:25 <johill> an xmlrpc implementation has to cope with getting an error anyway
2007-09-05T15:08:52 <xorAxAx> johill: yes, the question is whether it passes the message in case of a 4xx response
2007-09-05T15:08:54 <johill> and special-casing xmlrpc just because it's xmlrpc doesn't seem good
2007-09-05T15:08:58 <xorAxAx> btw
2007-09-05T15:09:13 <xorAxAx> i would issue a 4xx response with a message in the header and a fault in the body
2007-09-05T15:09:23 <xorAxAx> i think that might satisfy most implementations
2007-09-05T15:09:36 <xorAxAx> johill: its a wholly different subprotocoll
2007-09-05T15:09:38 <johill> heh, interesting, but why would implementations read the body if they got a 403?
2007-09-05T15:09:46 <xorAxAx> johill: because your browser does as well?
2007-09-05T15:09:54 <johill> yes but it runs on top of http so it has to be able to cope with http errors
2007-09-05T15:09:57 <ThomasWaldmann> File "/usr/lib/python2.4/xmlrpclib.py", line 744, in close
2007-09-05T15:09:57 <ThomasWaldmann> raise Fault(**self._stack[0])
2007-09-05T15:09:57 <ThomasWaldmann> xmlrpclib.Fault: <Fault 1: 'This moin wiki does not allow xmlrpc calls.'>
2007-09-05T15:09:58 <xorAxAx> i mean, you seem to contradict yourself a bit :)
2007-09-05T15:10:07 <johill> xorAxAx: only because I don't use IE :)
2007-09-05T15:10:21 <johill> xorAxAx: that's a human readable thing though, xmlrpc is designed to be machine readable
2007-09-05T15:10:37 <johill> hence, I don't think xmlrpc can assume getting a valid xmlrpc response if the http layer errored out
2007-09-05T15:10:43 <xorAxAx> and winfo-readable
2007-09-05T15:11:19 <johill> it's like you don't even try to read IP packets that have an invalid layer 2 checksum
2007-09-05T15:11:36 <xorAxAx> not sure
2007-09-05T15:12:08 <xorAxAx> xmlrpc is on the same level as http in the usual tcp model
2007-09-05T15:12:17 <johill> or in wireless, you won't look at a packet if the frame checksum fails even if the beginning may well have been correct
2007-09-05T15:12:25 <johill> well that's because osi doesn't offer more layers
2007-09-05T15:12:31 <johill> in practice, it's layered into http
2007-09-05T15:12:43 <xorAxAx> no, thats because they are interleaved in terms of dependencies and links
2007-09-05T15:13:04 <johill> I mean, it uses http as a transport, so how can it assume the response is readable if the transport layer errored out
2007-09-05T15:13:08 <johill> ?
2007-09-05T15:13:18 <xorAxAx> you cannot implement xmlrpc without http
2007-09-05T15:13:24 <xorAxAx> because there are circular dependencies
2007-09-05T15:13:39 <johill> seriously? it's more crappy then I thought then
2007-09-05T15:13:59 <xorAxAx> well, look into the RFC
2007-09-05T15:14:21 <xorAxAx> umm
2007-09-05T15:14:39 <xorAxAx> there is none
2007-09-05T15:15:00 <johill> http://www.xmlrpc.com/spec?
2007-09-05T15:15:06 <johill> not an rfc per se, of course
2007-09-05T15:15:51 <johill> I don't see anything in there that precludes transporting it over something else
2007-09-05T15:16:55 <xorAxAx> "An XML-RPC message is an HTTP-POST request."
2007-09-05T15:17:02 <xorAxAx> "The body of the request is in XML"
2007-09-05T15:17:12 <xorAxAx> "Here's an example of an XML-RPC request:"
2007-09-05T15:17:25 <xorAxAx> " However, if the server is handling a mix of incoming HTTP requests, we allow the URI to help route the request to the code that handles XML-RPC requests."
2007-09-05T15:17:34 <xorAxAx> "A User-Agent and Host must be specified.
2007-09-05T15:17:34 <xorAxAx> The Content-Type is text/xml.
2007-09-05T15:17:34 <xorAxAx> The Content-Length must be specified and must be correct."
2007-09-05T15:17:37 <johill> well
2007-09-05T15:17:43 <johill> apart from that nonsense
2007-09-05T15:17:50 <xorAxAx> "Here's an example of a response to an XML-RPC request:"
2007-09-05T15:17:51 <johill> if it was properly written it'd split that into two
2007-09-05T15:17:57 <xorAxAx> thats 50% of the doc
2007-09-05T15:18:06 <xorAxAx> "The Content-Type is text/xml. Content-Length must be present and correct.
2007-09-05T15:18:06 <xorAxAx> The body of the response "
2007-09-05T15:18:08 <johill> yeah, it's obviously not properly written
2007-09-05T15:18:21 <johill> but the core of the spec is
2007-09-05T15:18:23 <johill> (1) xml
2007-09-05T15:18:35 <johill> (2) the xml specification with methodCall, param etc
2007-09-05T15:18:38 <xorAxAx> nah, you are picking cherries out of the doc
2007-09-05T15:18:41 <johill> (3) how to wrap it into html
2007-09-05T15:19:04 <johill> eh, http
2007-09-05T15:19:10 <johill> except they don't properly specify it that way
2007-09-05T15:19:59 <johill> btw
2007-09-05T15:20:01 <johill> "Unless there's a lower-level error, always return 200 OK."
2007-09-05T15:20:10 <johill> not having xmlrpc available is a "lower-level error"
2007-09-05T15:20:45 <ThomasWaldmann> but if we answer with a xmlrpclib.Fault(), aren't we doing xmlrpc? X)
2007-09-05T15:21:02 <xorAxAx> johill: its not
2007-09-05T15:21:04 <xorAxAx> IMHO :)
2007-09-05T15:21:20 <xorAxAx> ThomasWaldmann: yes, and thats fine
2007-09-05T15:21:40 <xorAxAx> you may reword the error to "xmlrpc methods" if you are so nitpicky :)
2007-09-05T15:21:57 <ThomasWaldmann> "we speak xmlrpc and answer requests, we just do not what client wants"
2007-09-05T15:22:56 <johill> ThomasWaldmann: yeah, if we return a fault then we can't return 403
2007-09-05T15:22:59 <johill> according to this
2007-09-05T15:23:25 <johill> xorAxAx: well, that's a question of policy really. what if I don't have xmlrpc libs installed?
2007-09-05T15:23:34 <johill> and why treat that different from "disabled"?
2007-09-05T15:23:51 <ThomasWaldmann> xmlrpc is stdlib
2007-09-05T15:23:59 <johill> well, assuming I could remomve it
2007-09-05T15:24:04 <ThomasWaldmann> response = xmlrpclib.Fault(1, "This moin wiki does not allow xmlrpc method calls.")
2007-09-05T15:24:10 <ThomasWaldmann> better?
2007-09-05T15:24:38 <xorAxAx> IMHO fine
2007-09-05T15:24:38 <johill> the spec is pretty awful anyway
2007-09-05T15:24:46 <johill> it doesn't tell you what to do on parser errors and other things
2007-09-05T15:25:04 <ThomasWaldmann> johill: if you remove xmlrpclib, moin would just crash
2007-09-05T15:25:22 <johill> I know
2007-09-05T15:25:36 <johill> but I don't see why it would have to
2007-09-05T15:25:52 <johill> to me, not having xmlrpc enabled ought to be equivalent to not being able to speak xmlrpc at all
2007-09-05T15:26:01 <johill> obviously, xorAxAx disagrees
2007-09-05T15:26:09 <ThomasWaldmann> we can change that in 1.7, later
2007-09-05T15:26:26 <xorAxAx> johill: i am thinking primarily about the clients
2007-09-05T15:26:41 <johill> (plus, special casing xmlrpc disabled over other actions just feels weird to me)
2007-09-05T15:26:42 <ThomasWaldmann> what i want to do now (and also for 1.6) is a means that someone can choose to serve xmlrpc (or not)
2007-09-05T15:26:49 <xorAxAx> and in fact, we rather have an upper level error than a lower level one (http) here
2007-09-05T15:27:11 <johill> xorAxAx: but that's the core of our disagreement, no need to talk about clients
2007-09-05T15:27:37 <johill> xorAxAx: I think that if we're not going to serve xmlrpc we shouldn't reply in xmlrpc since we just said it was disabled
2007-09-05T15:27:53 <xorAxAx> johill: no, we didnt, we just said that methods are disabled, not xmlrpc itself
2007-09-05T15:28:19 <johill> xorAxAx: uh, wait, are we talking about two different things now?
2007-09-05T15:28:30 <johill> are you still talking about disabling just 'putPage'?
2007-09-05T15:28:38 <johill> fwiw, I was talking about disabling xmlrpc completely
2007-09-05T15:28:51 <xorAxAx> johill: yes, we are talking about disabling all xmlrpc methods
2007-09-05T15:29:06 <xorAxAx> if they are disabled, the wiki still understands xmlrpc but doesnt execute it
2007-09-05T15:29:16 <johill> oh well
2007-09-05T15:29:20 <xorAxAx> instead it returns an error message saying that all xmlrpc methods are disabled :-)
2007-09-05T15:29:38 <johill> see, the way I see it xmlrpc is completely disabled if you disable the xmlrpc action
2007-09-05T15:29:47 <xorAxAx> thats like me answering "je ne parle plus francais" when somebody asks "parlez-vous francais?"
2007-09-05T15:29:59 <johill> yeah that's what you're proposing
2007-09-05T15:30:19 <xorAxAx> instead of me making weird sounds or running away :-)
2007-09-05T15:30:36 * johill imagines xorAxAx pronouncing that and balances against "weird sounds" :P
2007-09-05T15:30:51 <xorAxAx> "balances"?
2007-09-05T15:31:04 <johill> well, wonder if it would be weird sounds :)
2007-09-05T15:31:09 <johill> anyhow
2007-09-05T15:31:11 <johill> I don't really care
2007-09-05T15:31:18 <johill> I just don't see the point in putting special-case code there
2007-09-05T15:31:26 <johill> when we already very well deny access to disabled actions
2007-09-05T15:31:29 <xorAxAx> its a different language :)
2007-09-05T15:31:48 <johill> no, it's http on steroids
2007-09-05T15:32:08 <johill> so if you return an http error obviously xmlrpc can't work
2007-09-05T15:32:46 <johill> imagine there exists some way to signal "I don't understand you" in natural languages that everybody understands
2007-09-05T15:33:00 <johill> and now you say "je ne parle pas francais" instead
2007-09-05T15:33:25 <xorAxAx> johill: in HTTP, there doesnt exist such a return value
2007-09-05T15:33:27 <xorAxAx> 403 is forbidden
2007-09-05T15:33:33 <xorAxAx> forbidden itself is ambiguous
2007-09-05T15:33:44 <xorAxAx> because moin has ACLs and user accounts etc.
2007-09-05T15:34:02 <xorAxAx> thats why the error code message would be essential
2007-09-05T15:34:08 <johill> you could say 501
2007-09-05T15:34:09 <xorAxAx> to workaround the impreciseness of 403
2007-09-05T15:34:40 <johill> but that's probably more on a http level
2007-09-05T15:34:50 <johill> but you're wrong anyway
2007-09-05T15:34:57 <xorAxAx> " The server does not support the functionality required to fulfill the
2007-09-05T15:34:57 <xorAxAx> request. This is the appropriate response when the server does not
2007-09-05T15:34:57 <xorAxAx> recognize the request method and is not capable of supporting it for
2007-09-05T15:34:58 <xorAxAx> any resource."
2007-09-05T15:35:09 <johill> because if we deny access to a resource while speaking xmlrpc we give a fault
2007-09-05T15:35:11 <johill> as xmlrpc requires
2007-09-05T15:35:12 <xorAxAx> at least the described use case in the rfc doesnt fit it
2007-09-05T15:35:30 <xorAxAx> hmm?
2007-09-05T15:35:33 <johill> yeah you're right
2007-09-05T15:35:53 <johill> if we speak xmlrpc then by the xmlrpc spec we're not allowed to return 403 when acl checks fail
2007-09-05T15:35:57 <johill> we must return a fault
2007-09-05T15:36:10 <xorAxAx> yes
2007-09-05T15:36:24 <johill> so there is no ambiguity
2007-09-05T15:36:29 <xorAxAx> there is
2007-09-05T15:36:32 <xorAxAx> if you use 403
2007-09-05T15:36:44 <xorAxAx> think about a end user
2007-09-05T15:36:52 <xorAxAx> the one using the API
2007-09-05T15:36:58 <xorAxAx> also think about http basic auth
2007-09-05T15:37:05 <xorAxAx> which will yield 403 regularly
2007-09-05T15:37:13 <xorAxAx> (and may be used in conjunction with moin)
2007-09-05T15:37:59 <johill> then we should use 406
2007-09-05T15:38:10 <johill> since xmlrpc requests will tell taht they want text/xml back
2007-09-05T15:39:00 <xorAxAx> that would hide the cause of the error
2007-09-05T15:39:02 <johill> in any case, this discussion has convinced me that xmlrpc is such a mess I will surely never use it
2007-09-05T15:39:06 <johill> :)
2007-09-05T15:39:07 <xorAxAx> as an error message itself
2007-09-05T15:39:51 <johill> yeah I suppose the only way to get what you want is to return a fault and display it to the end user
2007-09-05T15:40:12 <johill> do we really use http basic auth?
2007-09-05T15:40:19 <johill> I thought that token stuff replaced it
2007-09-05T15:42:14 <xorAxAx> johill: moin never spoke basic auth, but it should able to be used in cases where some auth provider of the httpd uses http level auth and supplies and env var with a username
2007-09-05T15:42:43 <johill> how would the xmlrpc code know to use it though?
2007-09-05T15:42:54 <johill> well, whatever
2007-09-05T15:43:11 <CIA-27> moin: Thomas Waldmann <tw AT waldmann-edv DOT de> * 2799:eab2cd188ca6 1.7/MoinMoin/ (config/multiconfig.py xmlrpc/__init__.py): added 'xmlrpc' to actions_excluded default value, return Fault if xmlrpc action is excluded
2007-09-05T15:43:27 <johill> you convinced me in that xmlrpc is just a mess and this is the only way to handle it even if I still don't think it's a good way
2007-09-05T15:44:14 <ThomasWaldmann> (I will add/change docs after 1.6 backport)
2007-09-05T15:44:51 <xorAxAx> johill: it does know how to use it
2007-09-05T15:45:01 <xorAxAx> johill: that was the only way to authenticate before 1.6
2007-09-05T15:45:11 <johill> ah ok
2007-09-05T15:45:35 <ThomasWaldmann> having it completely disabled by default, we could even NOT use some additional flag for disabling write access
2007-09-05T15:46:28 <ThomasWaldmann> the one who enables it just needs to be informed that if he enables it, he opens his wiki to a quite fast and easy way of editing it by a script
2007-09-05T15:47:07 <johill> I'd love to see that somehow logged so it becomes easy to revert all xmlrpc usage if say wikisync went made
2007-09-05T15:47:10 <johill> s/made/mad
2007-09-05T15:47:18 <johill> I had it go mad a few times and gave up then
2007-09-05T15:50:01 <xorAxAx> johill: its logged in RC
2007-09-05T15:50:05 <xorAxAx> and despam should help
2007-09-05T15:50:06 <ThomasWaldmann> btw, 403 would just raise another error class in the client, a bit earlier
2007-09-05T15:50:48 <johill> yeah, despam could help
2007-09-05T15:51:04 <xorAxAx> ThomasWaldmann: in our client
2007-09-05T15:51:09 <xorAxAx> s/our/python's/
2007-09-05T15:51:14 <ThomasWaldmann> yes
2007-09-05T15:51:27 <ThomasWaldmann> no idea what others do
2007-09-05T15:52:07 <ThomasWaldmann> ok, I put that into 1.6 now also
2007-09-05T16:00:22 <ThomasWaldmann> * actions_excluded now defaults to ['xmlrpc'] - this kind of disables the
2007-09-05T16:00:22 <ThomasWaldmann> built-in wiki xmlrpc server code (not completely: it will just answer
2007-09-05T16:00:22 <ThomasWaldmann> with a Fault instance for any request). If you want to use xmlrpc v1 or
2007-09-05T16:00:22 <ThomasWaldmann> v2, you have to remove 'xmlrpc' from the actions_excluded list (for
2007-09-05T16:00:22 <ThomasWaldmann> example if you want to use wikisync, mailimport or any other feature
2007-09-05T16:00:24 <ThomasWaldmann> using xmlrpc). If you enable xmlrpc, it will be possible that someone
2007-09-05T16:00:27 <ThomasWaldmann> changes your wiki content by using xmlrpc (it will of course honour ACLs).
2007-09-05T16:01:18 <ThomasWaldmann> is that clear enough?
2007-09-05T16:04:47 <dreimark> may be we should make clearer that you better have acls enabled and don't give anonymous write access if you enable xmlrpc
2007-09-05T16:05:14 <ThomasWaldmann> acls are ever "enabled"
2007-09-05T16:06:05 <dreimark> I know
2007-09-05T16:06:15 <ThomasWaldmann> and known vs. anon is a very weak wall
2007-09-05T16:06:41 <xorAxAx> xmlrpc -> http is even weaker
2007-09-05T16:06:48 <ThomasWaldmann> to have real protection, you need group member check
2007-09-05T16:07:02 <dreimark> justt remove the brackets. It will of course honour ACLs!
2007-09-05T16:07:25 <xorAxAx> dreimark: why?
2007-09-05T16:08:24 <dreimark> if you have group member check then you have setup acl rules and then its controlled by those users.
2007-09-05T16:09:00 <xorAxAx> ?
2007-09-05T16:09:02 <dreimark> always all things needs to honour ACLs
2007-09-05T16:09:12 <xorAxAx> well, right
2007-09-05T16:09:17 <xorAxAx> just to reassure users
2007-09-05T16:10:03 <dreimark> So we don't need to use this sentence in brackets. If we do we want to give a hint why better use acls if we enable this feature
2007-09-05T16:11:06 <dreimark> So we need some sentence which tells which setup you should use if you enable this feature
2007-09-05T16:11:47 <xorAxAx> the default setup is fine
2007-09-05T16:12:13 <dreimark> I guess we need some scenario descriptions on MMaster
2007-09-05T16:12:24 <xorAxAx> i dont see any use
2007-09-05T16:13:37 <dreimark> We have some nice features added to 1.6. e.g. wikisync
2007-09-05T16:13:57 <xorAxAx> yes but why does that form a new configuration scenario?
2007-09-05T16:14:11 <xorAxAx> except that you need to remove the setting thomas just committed
2007-09-05T16:14:13 <dreimark> oh, no. Examples
2007-09-05T16:14:22 <xorAxAx> of what?
2007-09-05T16:15:36 <dreimark> everyones wiki, some user wiki (no write for anonymous), complete moderated wiki
2007-09-05T16:16:06 <dreimark> something like this. And it must be clear that's not a good idea to enable it for everyones wiki
2007-09-05T16:16:56 <xorAxAx> dreimark: why the hell isnt it?
2007-09-05T16:18:08 <dreimark> despam does not restore currently removed attachments.
2007-09-05T16:18:42 <xorAxAx> how is that related an xmlrpc action?
2007-09-05T16:18:59 <dreimark> an xmlrpc action could del an attachment
2007-09-05T16:19:10 <xorAxAx> it makes it indeed hazarderou in this case, but the attachfile action is hazarderous as well
2007-09-05T16:19:26 <xorAxAx> i need 10 minutes to write an attachment pruner without using xmlrpc
2007-09-05T16:19:44 <xorAxAx> so i still dont see the point
2007-09-05T16:19:54 <xorAxAx> compared to deletepage, attachfile doesnt even use a ticket
2007-09-05T16:20:02 <xorAxAx> so i just need 1 request per deleted attachment
2007-09-05T16:20:12 <dreimark> xorAxAx: does this pruner purge if the user does not have acl rights?
2007-09-05T16:20:30 <xorAxAx> dreimark: in an average wiki, i would need to login - same for xmlrpc
2007-09-05T16:20:35 <xorAxAx> dreimark: doesnt make it more difficult
2007-09-05T16:20:55 <dreimark> as Thomas sad to have real protection, you need group member check
2007-09-05T16:21:09 <dreimark> that needs to be descibed
2007-09-05T16:21:11 <xorAxAx> you should realise that xmlrpc is not the threat
2007-09-05T16:21:15 <xorAxAx> ?
2007-09-05T16:22:06 <tic> is wikisync a cmdline tool
2007-09-05T16:22:07 <tic> ?
2007-09-05T16:22:16 <xorAxAx> tic: no, an action
2007-09-05T16:22:27 <tic> xorAxAx, how do you use it?
2007-09-05T16:22:36 <xorAxAx> tic: if your current page is a job description for a wikisync job, you select the action and start the sync
2007-09-05T16:22:43 <xorAxAx> has been working fine for a year :)
2007-09-05T16:23:09 <xorAxAx> tic: a minimal sync job is one line - and the template has a macro call in it that gives you a link "start a sync"
2007-09-05T16:23:13 <xorAxAx> so its pretty easy to use
2007-09-05T16:23:49 <dreimark> if you do group member check, you don't exclude that one purges the wiki, but you have some more control over the people in that group
2007-09-05T16:23:59 <xorAxAx> dreimark: ?
2007-09-05T16:24:11 <xorAxAx> when will you check for group membership?
2007-09-05T16:24:21 <dreimark> xorAxAx: setting up the wiki
2007-09-05T16:24:38 <xorAxAx> ???
2007-09-05T16:25:14 <dreimark> I do enable different groups with different rights and I do know the people I put in the groups
2007-09-05T16:25:47 <dreimark> so its human approved
2007-09-05T16:26:04 <xorAxAx> what would the groups be used for?
2007-09-05T16:26:30 <dreimark> to control who has write access to which page for example
2007-09-05T16:27:22 <xorAxAx> you are currently describing how ACLs work
2007-09-05T16:27:29 <tic> xorAxAx, are there any docs for that? :)
2007-09-05T16:27:34 <xorAxAx> tic: of course
2007-09-05T16:27:38 <dreimark> tic see MoinMaster
2007-09-05T16:27:39 <xorAxAx> tic: been there for a year
2007-09-05T16:27:52 <xorAxAx> tic: search for sync :)
2007-09-05T16:27:55 <tic> right, thanks!
2007-09-05T16:28:50 <tic> test17 or test16?
2007-09-05T16:31:52 <xorAxAx> tic: master.moinmo.in
2007-09-05T16:32:10 <xorAxAx> (as described on the frontpage of moinmo.in
2007-09-05T16:33:56 <dreimark> xorAxAx: currently we tell in Thomas comment : If you enable xmlrpc, it will be possible that someone changes your wiki content ... I think we should give a more detailed hint about what you have to do if you want to use it.
2007-09-05T16:34:25 <xorAxAx> dreimark: "use" - you mean the user use cases?
2007-09-05T16:34:30 <dreimark> yeah
2007-09-05T16:35:35 <xorAxAx> his text block was for the changes file which lists all new features. yes, it might make sense to talk about this in the help pages as welll
2007-09-05T16:35:58 <xorAxAx> ThomasWaldmann: can you modify all affected help pages with a hint that a config change is necessary to use the feature?
2007-09-05T16:39:10 <ThomasWaldmann> xorAxAx: yeah
2007-09-05T16:39:28 <ThomasWaldmann> wikisync, emailimport. anything else coming to mind?
2007-09-05T16:40:11 <xorAxAx> jabber
2007-09-05T16:40:13 <xorAxAx> in 1.7
2007-09-05T16:45:12 * ThomasWaldmann feels we still did not find the right means of limiting xmlrpc.
2007-09-05T16:45:51 <ThomasWaldmann> the jabber and emailimport stuff will usually done by some trusted host (localhost, mailserver, jabberserver).
2007-09-05T16:46:20 <xorAxAx> yes
2007-09-05T16:46:48 <ThomasWaldmann> wikisync may or may not be some specific host
2007-09-05T16:47:48 <tic> will you provide with a migration script doing s/\[\[\(.*\)\]\]/<<\1>>/g for pre-1.6 wikis?
2007-09-05T16:47:49 <ThomasWaldmann> and then we have those secrets...
2007-09-05T16:48:09 <ThomasWaldmann> tic: yes, see MoinMoin/script/migration
2007-09-05T16:48:24 <ThomasWaldmann> (and it is MUCH more complex)
2007-09-05T16:50:02 <tic> of course it is :)
2007-09-05T16:52:40 <ThomasWaldmann> tic: it is a modified 1.5.8 parser, that doesn't call the html formatter, but spills out new markup.
2007-09-05T16:55:04 <tic> ThomasWaldmann, clever.
2007-09-05T16:56:28 <ThomasWaldmann> yeah, but took some time
2007-09-05T17:04:27 <dreimark> ThomasWaldmann: that was the reason why I thought we need some global vars: enable_mailimport, enable_jabber, enable_mail_sending ...
2007-09-05T17:05:09 <xorAxAx> dreimark: mailimpor tcan also be done without xmlrpc
2007-09-05T17:05:30 <xorAxAx> so i dont see how this is related to the evil xmlrpc monster
2007-09-05T17:06:15 <ThomasWaldmann> dreimark: mailimport uses a shared secret. if you dont have it, it wont work.
2007-09-05T17:06:21 <dreimark> fine
2007-09-05T17:06:35 <dreimark> and jabber too I guess or
2007-09-05T17:06:44 <ThomasWaldmann> no idea
2007-09-05T17:06:57 <xorAxAx> yes
2007-09-05T17:07:09 <ThomasWaldmann> but i would like to consolidate that stuff
2007-09-05T17:07:21 <ThomasWaldmann> so we have secrets = {
2007-09-05T17:07:31 <ThomasWaldmann> 'emailimport': ...,
2007-09-05T17:07:34 <ThomasWaldmann> ...
2007-09-05T17:07:36 <ThomasWaldmann> }
2007-09-05T17:11:43 <dreimark> sounds ok
2007-09-05T17:25:48 <ThomasWaldmann> otoh, we could also have something like "system users"
2007-09-05T17:50:20 * starshine peeks in
2007-09-05T17:50:54 <starshine> oh no, another term to confuse everyone about what kind of deities we can have over pages.
2007-09-05T17:58:30 <ThomasWaldmann> well, users are already known. so it is rather the questions whether we keep the additional secrets or have some other kind of users.
2007-09-05T18:25:10 <starshine> nod
2007-09-05T18:32:39 <dreimark> starshine_away: ?
2007-09-05T18:33:55 <dreimark> bbl
2007-09-05T19:01:27 <grzywacz> moin
2007-09-05T19:08:04 <ThomasWaldmann> hi grzywacz
2007-09-05T19:10:16 <tic> czesc
2007-09-05T20:20:49 <starshine> back
2007-09-05T20:30:20 <ThomasWaldmann> hi starshine
2007-09-05T20:32:33 <starshine> heya
2007-09-05T20:33:11 <ThomasWaldmann> flights booked :)
2007-09-05T21:08:15 <CIA-27> moin: Thomas Waldmann <tw AT waldmann-edv DOT de> * 2150:e64b74c9e6ed 1.6/MoinMoin/ (config/multiconfig.py xmlrpc/__init__.py): added 'xmlrpc' to actions_excluded default value, return Fault if xmlrpc action is excluded
2007-09-05T21:08:17 <CIA-27> moin: Thomas Waldmann <tw AT waldmann-edv DOT de> * 2151:99bb43a31752 1.6/docs/CHANGES: updated CHANGES with new actions_excluded default
2007-09-05T21:08:18 <CIA-27> moin: Thomas Waldmann <tw AT waldmann-edv DOT de> * 2152:80fe84cf315f 1.6/MoinMoin/ (action/info.py stats/hitcounts.py): merged main
2007-09-05T21:53:13 <dreimark> As I have introduced mimetypes_embed for embedObject I thought its a good idea to have positive select list
2007-09-05T21:53:40 <dreimark> for mimetypes which should be embedded
2007-09-05T21:54:44 <dreimark> I am not sure if this extra control is wanted
2007-09-05T21:55:13 <dreimark> In the case of application/x-shockwave-flash'
2007-09-05T21:55:37 <dreimark> you have to remove it from mimetypes_xss_protect and to enter into mimetypes_embed
2007-09-05T23:47:26 <ThomasWaldmann> re MoinMoin: MoinMoinChat/Logs/moin-dev/2007-09-05 (last edited 2007-10-29 19:08:11 by localhost)
