#foswiki 2014-12-02,Tue

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
GithubBot[distro] gac410 pushed 1 new commit to master: http://git.io/q9ELYQ
distro/master 611e19d George Clark: Item12969: Don't validate strikeone for GET...
[02:31]
***GithubBot has left [02:31]
............................ (idle for 2h16mn)
gac410 has left [04:47]
........................ (idle for 1h55mn)
ChanServ sets mode: +o CDot [06:42]
................... (idle for 1h30mn)
GithubBot[CaptchaPlugin] MichaelDaum pushed 2 new commits to master: http://git.io/LiOpvw
CaptchaPlugin/master 485e21d MichaelDaum: Item13030: moving from jquery.tmpl to jsrender
CaptchaPlugin/master 3c2df3a MichaelDaum: Item13030: up'ing dependency on JQueryPlugin 6.00...
[08:12]
***GithubBot has left [08:12]
GithubBot[JQGridPlugin] MichaelDaum pushed 1 new commit to master: http://git.io/1ndQ6g
JQGridPlugin/master 7114c3f MichaelDaum: Item13030: moving to jsrender
[08:17]
***GithubBot has left [08:17]
GithubBot[BlogPlugin] MichaelDaum pushed 1 new commit to master: http://git.io/tBgPpw
BlogPlugin/master 08cfd44 MichaelDaum: Item13121:Item13030: new auto-publish feature...
[08:27]
***GithubBot has left [08:27]
........ (idle for 37mn)
ChanServ sets mode: +o MichaelDaum [09:04]
..... (idle for 24mn)
GithubBot[distro] MichaelDaum pushed 2 new commits to master: http://git.io/etbKbg
distro/master 52c80e6 MichaelDaum: Item13105: delay execution of SEARCH examples...
distro/master 93f701c MichaelDaum: Merge branch 'master' of github.com:foswiki/distro
[09:28]
***GithubBot has left [09:28]
GithubBot[distro] MichaelDaum pushed 1 new commit to master: http://git.io/sC7T5Q
distro/master 2b160f3 MichaelDaum: Item13105: put topics into a bracket link
[09:33]
***GithubBot has left [09:33]
.................. (idle for 1h29mn)
JulianLevensFor release 1.2 we are keen to deliver PFS
As I have discussed in Item13100 there is the related point about lack of PolyStore support which IMO suggests delaying PFS
This impacts Item13068 and Item13078 which relate to PFS
[11:02]
I would love to deliver PFS with 1.2, but I am concerned that to do that properly (with PolyStore support) will unnecessarily delay the release [11:09]
.................... (idle for 1h39mn)
GithubBot[JQTablePlugin] MichaelDaum pushed 1 new commit to master: http://git.io/zHVh8Q
JQTablePlugin/master 046d75b MichaelDaum: Item13112: add javascript based date parser
[12:48]
***GithubBot has left [12:48]
CDotJulianLevens: why is PFS dependant on PolyStore? [12:54]
JulianLevensDid you read Item13100? PFS itself is not par se but ... [12:55]
GithubBot[JQTablePlugin] MichaelDaum pushed 1 new commit to master: http://git.io/6s5Otw
JQTablePlugin/master c8febc6 MichaelDaum: Item13112: fixing jslint errors
[13:02]
***GithubBot has left [13:02]
CDotyes, I read it, but I remain to be convinced that multiple store implementations need to co-exist. So long as a "no store" option exists - as it does for all the existing stores - so that they can fall back to a "simple text topics" implementation, then the rest of the store can be done using a single implementation.
Switching between implementations is a breeze, using tools/bulk_copy.pl
[13:03]
JulianLevensSorry, we are at cross purposes [13:03]
CDotwe are? [13:03]
JulianLevensYes, I'm concerned about FW currently being MonoStore - you can have any store you like as long as its RCS
To move to a PolyStore world the tools and documentation need to support that and I'm raising the point that a blind copy_store is not enough; there are other use cases
Oh and I'm talking much more about Install processes not a running Foswiki
[13:04]
CDot"you can have any store you like as long as its RCS" - where do you get that from? That is definitely not the case. Yes, install doc is required, but there is no technical obstacle. All of your use-cases can be addressed with what we already have (+ doc) [13:11]
JulianLevensI know that another store is possible (for some time) as long as the Administrator is aware enough of the topic-merge/upgrade issues and will manage them - but the Docs to date are sparse [13:15]
***ChanServ sets mode: +o gac410 [13:15]
CDotthe docs are sparse, and the testing is incomplete - I only wrote bulk_copy.pl a few days ago, after all. But it's really not such a big blocker as Item13100 is making out. [13:16]
JulianLevensWhat about installing an extension, by default the will copy into data/System/ExtensionTopic.txt [13:16]
CDotthat's fine.
As I said, all the existing stores support a fallback to plaintext if the web cannot be found in the store
so long as you don't import System into your store implementation, it works fine using the fallback.
[13:16]
JulianLevensI was rather hoping to install System into my Store implementation [13:17]
CDotwhy? [13:17]
JulianLevensHopefully speed - especially searches [13:18]
CDotyes, fair point [13:18]
JulianLevensI grant you it's not critical
or at least it's a reasonable fallback - I'd like to test it though
[13:18]
CDotthe search engines also have to be able to fall back - and TBH I haven't tested that anywhere like enough
but the idea holds; plaintext fallback allows extension installation using .txt
[13:18]
JulianLevensI hadn't recognised that fall back to be honest. With that in place a lot of my points are moot - I'll re-read
I'd like things to mature so fall back is either not required or can fall back at a single topic level
That's not hard really; it's just another StoreClass in Implementation classes
[13:20]
CDotthe real blockage in the system is where you have imported the entire store into an implementation, and then try to install an extension. That requires the extension installer wizard to use the methods of Foswiki::Meta to install new topics
not a huge problem, and next on my TODO list
[13:22]
GithubBot[JQTablePlugin] MichaelDaum pushed 1 new commit to master: http://git.io/bsMVXw
JQTablePlugin/master 5e7fa21 MichaelDaum: Item13129: don't process tables already init'ed...
[13:23]
***GithubBot has left [13:23]
CDotmore of a problem is the extension installer script embedded in release packages
and the "unzip to install" concept
[13:23]
JulianLevensyep [13:24]
CDotcos clearly an unzip isn't going to cut it unless you are using a .txt store [13:24]
JulianLevensIt's possibly OK as a 1st step, but as you say ... [13:24]
CDot: I've updated the Task to reflect our discussion [13:34]
CDot:-) [13:34]
JulianLevensWe do need to consider create as a method of the Store API
sub create {} that is
But that's hardly a blocker
[13:35]
gac410CDot ... just some doc confusion .. Item13127 If you could clarify {Extensions} vs. {Plugins} I'll be glad to do the fixup later. IRC user was very confused last night, and so was I eventually :)
gotta run - back in 1/2 hour
[13:42]
CDotnamespace soup [13:44]
GithubBot[JQTablePlugin] MichaelDaum pushed 1 new commit to master: http://git.io/Y5SpIw
JQTablePlugin/master bdbd836 MichaelDaum: Item13130: better column sort icons
[13:45]
***GithubBot has left [13:45]
.... (idle for 16mn)
JulianLevensCDot: bulk_copy.pl is interesting; I only learnt about forking yesterday (the programming detail that is) for FastCGI reasons [14:01]
CDotmy main concern with the current implementation is partial-copy recovery i.e. what happens if it dies halfway through.
I *think* it will recover, but can't be 100% sure.
Also, it doesn't currently chunk attachment transfers, so the memory footprint may be very large
[14:02]
JulianLevensOk, I'll bear that in mind
and that too
My tools had built in timing as I wanted to check out performance - but that's a different animal
[14:03]
gac410CDot, I'm with ya on the Extensions v.s. Plugins. But *everything* uses {Plugins} as the root of settings. branching out into {Extensions} and {Plugins} makes it more confusing .. now two places to look, and do we really want to try to change all the existing stuff?
Well everything except one contrib from you, and a really messed up CKEditor spec.
So changing all the existing stuff ... I'd vote no, just changes for sake of it IMO. And with 99% under Plugins, adding {Extensions} seems like just making it more confusing.
I do agree, Plugins are extensions. so your change in a clean sheet environment is 100% correct.
Did you see my debugging on http://foswiki.org/Tasks/Item13096 Seems to be a bug in javascript maybe? I am unable to comment using firefox. Chromium works fine. If I "Step over" the alert in the js, then everything works as expected.
The error string is empty, so I have no idea why the alert is triggered. Annoying.
I don't really understand the $.ajax stuff. So I have no idea how to tell if the alert should not have been triggered, or if there really was an error that did't say why.
[14:11]
GithubBot[JQTablePlugin] MichaelDaum pushed 1 new commit to master: http://git.io/dHeMJA
JQTablePlugin/master cd3a382 MichaelDaum: Item13131: remove dependency on CGI.pm...
[14:22]
***GithubBot has left [14:22]
gac410fsfs are you around? your nightly tests need a new perl module. CGI::Session was removed from the distro
gmc_: are you going have some time sometime. need to chat about f.o server maybe best on admin channel.
[14:24]
CDotgac410: probably not, and I'm sorta ok with {Plugins}{...}. What I'm *not* OK with is extension settings at the top level e.g. $Foswiki::cfg{JQueryPlugin} as it gets horribly messy for =configure=
oh, and I'm definitely *not* ok with a Contrib using a namespace under {Plugins}. That *would* be confusing.
CDot has a couple of contribs that include bundled Plugins. keeping that clean means keeping the namespaces well separated.
[14:28]
gac410Okay ... I'll try to fix up the docs. BuildContrib says to use the top level. I'll try to make some sense out of it and still document a bit of history for someone pondering an old plugin. [14:31]
CDotOn 13096... did you try the code in the 1.2 repository?
it's very different
[14:34]
gac410I'm using trunk.foswiki.org CDot
our live site So whatever is running there..
[14:35]
CDotyou can't be - that JS code fragment you posted is from 1.1.9 [14:35]
gac410That makes no sense. I was logged into trunk.foswiki.org and commenting on a Sandbox task.
Specifically http://trunk.foswiki.org/Sandbox/TestItem13027Failure
And running the javascript debugger in the ff window,.
That code was c/p from the debugger.
[14:36]
CDotno wait, sorry, my brain was on subscribeplugin [14:37]
gac410Ah... okay :) [14:37]
CDotanyways, it sounds like a double submission. Possibly the submit is getting repeated in FF. I vaguely recall it doing that before.
Should be easy to spot in firebug
does the comment get added?
[14:38]
gac410Running FF 24.6.0 Actually firebug was useless. No comment does not get added.
If I "Step over" the alert, then comment is added fine, If I let it run normally, then I get Error: alert, the screen clears, and a 403 error is displayed in plaintext
firebug just remains blank. No error in js console. opaque. "it just doesn't work" ... That's why I ended up stepping through with the debugger.
[14:38]
CDot:-(
don't suppose you ran wireshark on it?
[14:40]
gac410It happens quickly. I can try wireshark. just take a moment.
cdot. May take a bit to dissect. Error box pops up for about 1/2 second, and then screen clears and the 403 appears. Hopefully I can figure out from packet timings where what happened.
[14:41]
CDotas I said it sounds like a douyble submission. if there's only one, look at the decoded packet. If the validation param starts with a ? then it's a JS problem/ [14:45]
gac410Okay. that was quick. Nothing in the trace until AFTER the error dialog. Then the 403
Single submission.
[14:45]
CDotok, so look at the post; what is the validation param?
(in wireshark)
[14:46]
gac410hang on ... my wireshark filter got whacked.
The post happened without any strikeone at all. Multipart form with ONLY field comment
[14:47]
CDotok, that smells of a JS problem. Unless the fom had no validation input in it?
CDot tries to reproduce it locally.
[14:50]
gac410so definitely not a double submission. The error pops up first, and then the post and 403
yes. browser dependent. chromium works fine. firefox on linux tanks.
Form has validation input
If I step over the error, then it works fine.
[14:51]
CDotbut it isn't sent in the POST? [14:52]
GithubBot[distro] MichaelDaum pushed 1 new commit to master: http://git.io/qDwrPw
distro/master f2eb8e3 MichaelDaum: Item13132: tabpane depends on easing...
[14:52]
***GithubBot has left [14:52]
gac410correct [14:52]
CDotwowza
what rev of FF?
[14:52]
gac41024.6
A bit old but not ancient
[14:52]
CDotI have 33 and it also plops [14:54]
gac410Ah good. So not just me and the original poster. I'm reasonably clueless on javascript and especially ajax, so I'm just stumbling in the dark. [14:55]
CDothmmm; i see a double submission [14:56]
gac410really? maybe I missed it in my wireshark. [14:56]
CDotno, I'm looking in Firebug
not got as far as wireshark
I see the first submission as the correct POST (with the right validation code)
then before any response is received there's a second submission
[14:57]
gac410From wireshark I see only a single POST. [14:58]
CDotinteresting
I see two posts, but there is no response to the first post
[14:58]
gac410Just reset my filter and only filter by IP.addr (was doing a follow stream) [14:59]
CDotCDot fires up wireshark [14:59]
gac410I reload the page at the 38 second mark, and then a single post at the 125 second mark. Nothing in between. [14:59]
CDotok, I see both POSTs in wireshark [15:02]
gac410really??? /me looks again [15:02]
CDotI suspect what is happening is that JQuery isn't stopping the submit even from bubbling [15:02]
gmc_gac410: tonight i might have a moment (2 to 3 hours from now) [15:03]
gac410gmc_: okay I should be around ... ping me and I'll try to remember to leave my speaker on :) Thanks
I filtered on HTTP, and in my whole trace there is exactly one POST
[15:04]
CDotthe funny thing is I get a 404 from the first POST... with a param of SCALAR(0xCAFEBABE) [15:04]
gac410maybe different js versions are behaving differently [15:05]
CDot^param^body
not sure if it' JS
[15:05]
gac410just for another datapoint i fired up Konqueor and it works fine there. [15:07]
CDotyeah, looks like FF handles <input type="submit" differently to all other browsers
other browser suppress the submit event if a click handler is installed, but it looks like FF doesn't
[15:07]
MichaelDaumhave you got a "return false;" at the end of your click handler?
otherwise it bubbles
[15:08]
gac410hm... trying ff on android, I don't get the left bar . [15:10]
CDotMichaelDaum: I fear it's more subtle than that [15:10]
MichaelDaumhave you got the file to look at? [15:11]
CDotdoes a input type=button work as a submit? [15:11]
MichaelDaumoh and make sure your if()s have brackets: if (test) { block; } --- always
comment.js is full of tabs as well
[15:11]
gac410Okay ... firefox on android fails same way. Error popup, followed by 403 text screen. [15:12]
MichaelDaumhard to say what goes on in this file w/o reformatting it [15:12]
gac410Plus a strange skin issue - no left bar. just the central body of the page [15:12]
MichaelDaum$("input.commentPluginAjax").click() does _not_ return false ... so it bubbles with the ajax() call terminating at a random time in between. [15:13]
CDothmmm, interesting. The response to the first post is a 404, but other browsers get a 401
MichaelDaum: adding a return false makes no difference. I've been down that route before (though you are right, it ought to be there)
[15:14]
MichaelDaumyou always need a return false at the end of a click handler. trust me.
as I said: the ajax call is then in a race condition with the bubbling event
[15:14]
***JulianLevens has left [15:16]
MichaelDaumcould be one cancels the other [15:16]
CDotok, so I understand what is going on now. Yes, you are right, the return false is needed, but the origin of the problem here is that a login is required on that page
when posting as an unauthorised user, I would expect a 401 response to the first POST, but when FF posts I see a 403
not worked out why yet :-(#
ok, so other browsers get a 403 as well, it's not just FF. So the perl isn't doing the right things.
[15:16]
gac410And on Dolphin on android, it just gives me a browser error "Error: Forbidden"
Dolphin has other issues too. No sidebar, and presented a browser login dialog, not the template login. yeesh.
[15:18]
CDotyeah, that's a 403
this is nothing to do with the browser, it's a coding issue in the server
[15:19]
gac410Strange then that Chrome works fine.
And konqueor too
[15:20]
MichaelDaummight have been better to %JQREQUIRE{"form"}% part of JQueryPlugin ... see http://malsup.com/jquery/form ... instead of your own form serialization code. [15:21]
CDotno, it doesn't. Try commenting as a non-logged-in user [15:22]
gac410er. trunk.foswiki.org requires login always [15:22]
CDotform.serialize is JQuery code
gac410: ok; so maybe there are three problems
[15:22]
MichaelDaumjquery.form lets you ajax-submit a standard form ... something you are trying to recode in comment.js again [15:23]
CDotinteresting - will look at that when I get back from studying the problem in hand [15:23]
gac410the 403 could be configuration? Need to not require auth when registering the rest handler. [15:23]
CDotoriginally CommentPlugin didn't need JQuery, which is why it was coded that way
gac410: quite likely
is t.f.o set up to rquire auth on REST calls?
[15:23]
gac410yes.
well.. no... let me check
[15:24]
CDotok. Hmm. [15:25]
gac410no. it does not. The github push is done unauthed [15:25]
CDotok. Where is that 403 coming from, then?
it's not the CommentPlugin code
has to be somewhere in UI/Rest.pm, I guess
[15:25]
gac410Is "AllowCommentByGuests enabled?
"GuestCanComment" is disabled, so auth is required.
[15:26]
CDotlooking at the error.log, it's rejecting the validation code [15:27]
gac410When CommentPlugin registers the rest handler, it tests GuestsCanComment when setting/clearing the authentication flag. [15:28]
CDotsorry, I take that back. i get no logged reason for the 403 [15:28]
gac410So that explains the 403 on trunk.foswiki.org [15:28]
CDotright
still not clear why I get no logged reason for the bump
CDot is looking at working/logs/error.log
[15:28]
gac410I think that this is unrelated. The post has the FOSWIKISID doesn't it? I think I saw it in the trace. [15:30]
CDoty
hmmm, the apache error log says "client denied by configuration". WTF?
CDot is using TemplateLogin. authz_core has no part in that
[15:30]
gac410Hm... log has lots of compile errors: BEGIN failed--compilation aborted at (eval 96) line 2., referer: http://trunk.foswiki.org/Sandbox/TabPaneTest
unrelated.
[15:32]
CDotunrelated [15:33]
gac410Just reminds me we need to review logs occasionally and create more task reports :) [15:34]
CDoty
what version of apache is being used on t.f,.o?
is there a "require all granted" in the httpd.conf?
[15:37]
gac410okay... the compile errors. missing FoswikirefsPlugin probably transient. That plugin is definitely there.
Apache 2.4.
I think we are using mod_authz_compat. Otherwise nothing would be working'
[15:40]
CDotok. Hmmm. [15:40]
gac410I have a new ApacheConfigGenerator that builds a complete 2.4 config. I should probably test it by rebuilding the trunk config. [15:41]
CDotCDot is clutching at straws, because the browser never sends an auth header with a REST request anyway
not when you are using TemplatLogin, anyway
[15:41]
gac410The rest posts from github are working just fine with no auth.
we can enable GuestsCanComment to see if that helps.
[15:41]
CDotnah; it's never reaching the perl code
the 403 is coming from Apache, AFAICT
it's got to be something to do with the headers; but what?
[15:44]
gac410Where are you seeing the denied by server config. I see a total of two in our trunk log. says access_compat error . GET on robots.txt and bin/view 61.135.189 host ip block [15:45]
CDotlocal [15:46]
gac410Ah... never mind.
I'm looking a t.f.o ... log seems clean.
[15:46]
CDotnot touched it, trying to understand locally
and I'm wrong, it's calling UI/Rest, so the 403 is happening somewhere in the perl
[15:46]
gac410if it calls UI/Rest, then it should come down to GuestCanComment setting.
unless I broked something
I made one minor change yesterday. bypass the validation tests if method = GET. strikeone only makes sens on POST
[15:47]
...... (idle for 26mn)
CDotsomehow a 404 sent back from commentPlugin is ending up as a 403 in the browser
still not sure how
[16:14]
gac410Something really strange is going on with Firefox (and Dolphin). All the other browsers seem quite happy. [16:16]
CDotMichaelDaum: u still around? [16:23]
MichaelDaumhalf way out [16:23]
CDotwanted to (quickly) discuss strikeone validation keys
in the SubscribePlugin, I changed it so a <form> is no longer required
it picks up the validation keys from (currently) a global JS var
and then replaces that var when the response comes in
the advantage is that the var could (potentially) be generated for each button
the disadvantage is that it requires inline JS in the <head>
there are obviously other methods. Curious to hear your opiniion.
[16:23]
MichaelDaumthis is related to Sven's try to create a foswiki.post() method [16:25]
CDotand? [16:26]
MichaelDaumdo I understand you correctly that this global JS var is holding your spare key? [16:26]
CDotnot a spare key; the *only* key used by the subscribe plugin [16:26]
MichaelDaumto be valid on a post [16:26]
CDotbut*only* used by the subscribePlugin [16:27]
MichaelDaumhow does the endpoint guarantee that it was only used by SubscribePlugin? [16:27]
CDotthis is closer to what I'd originally envisaged for strikeone; the use of form inputs was more driven by the need to maintain existing forms than anything else
it can't guarantee it, of course
but the key is a JS var, so is protected by same-origin
if you had another bit of JS loaded, it could use it
no different to any <input name="validation_key" in that respect.
[16:27]
MichaelDaumthis is only marginally better than having a validation_key generated by the core part of a <form> elem [16:29]
CDotnot sure it is any better at all [16:29]
MichaelDaumy [16:29]
CDotbut it's the best I could think of
my requirement wa to get rid of the <form> in subscribePlugin'
and not have to reap a key from some other form
the question to you is more one of "better to us inline JS or some other method"?
e.g. html5 params on the <a> implemeting the button
[16:29]
MichaelDaum<a class="subscribe_button" data-validation-key="xxx"> Subscribe</a> would be okay as well [16:30]
CDotit's ok so long as you assume html5
but then, i guess we do
[16:31]
MichaelDaumI just changed the doctype accordingly [16:31]
CDotoh, ok
I like data-validation better, because it locks down the key to a single button
[16:31]
MichaelDaumsee the sources of t.f.o : <!DOCTYPE html><html lang="en">
right.
[16:32]
CDottherefore (in throery) parallel rest requests are OK
yeah, I saw your checkin, just didn;t make the connection :-)
ok, so, let's standardise on HTML5 params
[16:32]
MichaelDaumwhat I don't know is in how far strikeone is still doing its job ... [16:33]
CDotwhat do you think might be stopping it? [16:33]
MichaelDaumwrt html5: I just changed JQTablePlugin's table.js to use html5 data-xxx attrs for table settings [16:34]
CDotyeah, IIRC EditRowPlugin uses data-xxx as well [16:34]
MichaelDaumcould you please explain to me - again - how strikeone works and what kind of scenarios it covers ... just to make sure we don't ease a javascript post too much ... bringing us back to square one [16:35]
CDotyou want me to repeat what I wrote already? or just point you at the link? :-) [16:38]
gac410btw CDot ...(don't hate me) ... SubscribePlugin has similar issues on Firefox. popup with "undefined" and subscription status doesn't change. Works on Chromium [16:38]
CDotgac410: ok, thanks
latest version?
[16:38]
gac410of ... ? [16:39]
CDotSubscribePlugin [16:39]
gac410I just enabled it on trunk.foswiki.org for the Sandbox web only.
So should be current to github within the last 15 minutes
[16:39]
CDotok [16:41]
GithubBot[distro] cdot pushed 1 new commit to master: http://git.io/WX1UlQ
distro/master 7bca1b4 Comment: Item13096: incorrect handling of unauthorised response
[16:45]
***GithubBot has left [16:45]
CDotMichaelDaum: basically as long as we are combining the code provided by the server with the secret (which is stored in a cookie) then we are not compromising it by having many codes. Of course we are expanding the attack surface, but not in a combinatorially signficant way.
the same risks exist as existed before (compromised JS served from the server being the main one)
[16:47]
GithubBot[distro] gac410 pushed 1 new commit to master: http://git.io/-sKPFg
distro/master 45560af George Clark: Item13127: Clarify config.spec documentation
[16:59]
***GithubBot has left [16:59]
gac410CDot ... I think that reflects our discussion on namespace. I'll try to bring HowToWrite into agreement. Maybe a %INCLUDE% of some of DeveopingPlugins would avoid duplicatino. [17:00]
gmc_gac410: ping :) [17:00]
gac410Hi gmc ... wanna head to foswiki-admin [17:00]
............... (idle for 1h12mn)
CDot ...one clarification. You said:
CDot: oh, and I'm definitely *not* ok with a Contrib using a namespace under {Plugins}. That *would* be confusing.
***CDot has a couple of contribs that include bundled Plugins. keeping that clean means keeping the namespaces well separated.
[18:12]
CDotyes? [18:12]
gac410So when a Contrib has a Plugin, Should that plugin *specific* settings live under Plugins or Extensions [18:13]
CDotunder Extensions [18:13]
gac410Okay. good. [18:13]
CDoteverything *except* Module and Enabled should be under Estensions (IMHO) [18:13]
gac410I'll make sure that is clearly reflected in the docs [18:13]
............ (idle for 57mn)
GithubBot[distro] gac410 pushed 1 new commit to master: http://git.io/QjtEPg
distro/master 6cee624 George Clark: Item13127: More changes to spec definitions.
[19:10]
***GithubBot has left [19:10]
gac410CDot ... okay I've finished munging System.DevelopingPlugins and Development.HowToWriteASpecFile ... [19:15]
..... (idle for 23mn)
GithubBot[distro] cdot pushed 3 new commits to master: http://git.io/WfAsHA
distro/master 9543f37 Comment: Item12926: bite the bullet and convert to using html5 data attributes to pass validation tokens in. This breaks old usages of the plugin but since these will certainly be modelled on the templates - which have been fixed - it shouldn't be too much of a problem.
distro/master 8024ca1 Comment: Item12926: bite the bullet and convert to using html5 data attributes to pass validation tokens in. This breaks old usages of the plugin but since these will certainly be modelled on the templates - which have been fixed - it shouldn't be too much of a problem.
distro/master 5242173 Comment: Item12926: bite the bullet and convert to using html5 data attributes to pass validation tokens in. This breaks old usages of the plugin but since these will certainly be modelled on the templates - which have been fixed - it shouldn't be too much of a problem.
[19:38]
***GithubBot has left [19:38]
CDotgac410: looks good
misplaced comma, but I'll let you away with that
[19:39]
gac410thanks. :P Grammar isn't one of my strong points, spelling nor either. [19:40]
CDotAt least you don't mis'place apos'trophies, like some turkey's :-)
food time
[19:41]
gac410its and it's always trips me up.
bon appitite (can't speel french either )
[19:41]
WOHOO! CDot ... COmmentPlugin working great now! Thanks [19:52]
***ChanServ sets mode: +o gac410
gac410 changes topic to: Channel logs: http://tinyurl.com/7atzrpz - Next Release Meeting Monday 15 Dec, 1300Z at #foswiki-release: http://tinyurl.com/mf4egh2
[20:02]
............... (idle for 1h13mn)
mephinethi! Thanks for improving the docs :-)
I'm currently installing the git version of foswiki (again), and one small annoyance that I see again is:
Extensions > UnitTestContrib > Configure > {UnitTestContrib}{Configure}{PERL} has 1 error
I guess that either the default is faulty here or the bootstrap automagic does something wrong.
If I manually push the "reset to default value" button, things get green again
[21:15]
Another strange thing is that the "Password" (Section Security+Authentication -> Passwords) is deprecated according to the description, but once it is set, you can't delete it without getting an error "The existing super admin password does not appear to be a valid password. You will be unable to access the super admin AdminUser (admin) using the current configuration. The password should be saved as an "$apr1:..." encoded pass [21:22]
................. (idle for 1h20mn)
gac410mephinet: Okay thanks. good feedback. On the UnitTestContrib config yeah there are some bugs in the PERL types. as well as in the merging of the spec. CDot has been up to his eyeballs in some operational bugs in CommentPlugin
Passwords - the original intention was to just do away with the sudo password. But after locking myself out more than once, I added it back in :)
I'd like to eventually add a way to encode the pw, maybe in js, not sure yet. but it indeed needs a way to unset it.
[22:42]
mephinetgac410: great! [22:45]
gac410Okay. the Error, probably should be a warning, but it is an attempt to prevent config lockout. This is a huge operational change, and we expect sites will lock themselves out
I made it an error because of another bug. Two "WARN" reports back to back get merged, and are tough to read
yeah I know .... lazy
It should probably only report that error when the AdminGroup is empty. meaning higher odds of lockout.
[22:49]
..... (idle for 22mn)
mephinet: Okay.... my checking logic is just a bit over the top. If you have a valid AdminGroup, or have a valid ConfigureFilter, there are way too many errors/warnings. [23:13]
.... (idle for 17mn)
GithubBot[distro] gac410 pushed 1 new commit to master: http://git.io/3aaWfA
distro/master af43c40 George Clark: Item13066: Another attempt at useful errors...
[23:30]
***GithubBot has left [23:30]
gac410mephinet: See if this is just a little bit more forgiving. You should be able to have an empty Password now.
And ConfigureFilter should probably be a simple csv list of users. Too easy to screw up a regex and allow too much access.
[23:32]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)