[00:28] SvenDowideit ... right. I agree, Just following Lavr's lead on that. However given that the upgrade package can be used to upgrade Version 1.1.0, it's best to really include most everything. [00:37] mmm, why? [00:38] * SvenDowideit will go humpf :) [00:38] actually, what i was thinking to do, is use the foswiki_releases github repo i have [00:38] basically compare the new release to the 1.1.0 one [00:39] When I was starting on 1.1.4, I used the FoswikiUpgradeCheck and identify all the updated files between a 1.1.0 tarball install I have here. and the latest build [00:39] y - git is far superior to tar :p [00:39] just run foswikiUpgradeCheck and grep for COPY [00:39] but the idea is the same [00:39] tar zxvf 1.1.0 [00:39] git init git add [00:39] rm -r foswiki [00:39] then tar zxvf 1.1.5 [00:39] git status [00:40] that'll tell you what should not have been removed, as its a patch release [00:40] cool - that would work too. [00:40] and what needs to be in the upgrde pkg [00:40] and thue git statsus | sed | mumble | tar czvf upgrade.tgz [00:41] I've been using foswikiUpgradeCheck for quite a while now, so that would work for me though. [00:41] if only he'd friggen written it in perl so we could all use it [00:41] or used the identical code i wrote in 2003 >mumble grumble< [00:42] yeah. agreed. [00:42] I've been tempted to rewrite ... but it works, and so much else to do. [00:42] what i want is fully automated builds, that we can then check [00:42] mumble :) [00:42] Trying to understand how CGI::Session works, so I can add the up-front login to configure. [00:43] i'm not sure thats the right thing todo [00:43] (sorry, thinking aloud [00:43] It's badly needed ... and that "other project" already has it. Though I don't like the implementation. [00:43] atm, if an admin walks away from configure [00:43] I'm looking at setting a 15 min expire on the session, with password re-validation on save. [00:43] then no-one can change anything, as you have to re-auth at every change stet [00:43] ah, ok, so session for view [00:44] Yes. [00:44] y - a huge improvement over what we have [00:44] Assume I can figure it out. :( [00:44] yup, we assume :) [00:44] you can go look at tmwiki's version too :) [00:45] Yeah I have. But they don't use sessions - pass in the password in a url param from what I could figure. configure has changed a lot ... use of Templates vs print of [00:45] omg. [00:45] i keep forgetting how much further along we are [00:46] ls [00:46] wrong window [00:46] :) [00:46] i was hoping to see all files in your root window! honest :) [02:13] ah, the strict JSON parsing. jQuery 1.4.something added this to use native browser functions where available, to speed it up. [02:15] So, I'm waiting for ADSL ports to become available on my street. I'm 300m from the mini-exchange but telstra has no ports available... so I have to wait for somebody else to cancel their service, or for Telstra to add more ports >:( [02:16] Funny, with 3 bars signal I can still only get 5-20KiB/sec of terribly bursty/jittery internet. [03:04] SvenDowideit: Is the configure issue new in 1.1.5? I'm getting totally tangled up in configure. I have CGI session and login working, but still have big issues with some of the actions, like install extensions, etc. [03:06] We can't save the password without saving the config. And saving the config breaks the 2-phase startup. Each thread I pull unravels big pieces of configure. [03:28] gac410, i don't think its really new [03:28] but its the first time i hit me in the face [03:28] basically, try this [03:28] someone is given a foswiki to admin [03:29] its been running for years [03:29] they remove the pwd on our advice [03:29] now they're in weirdo land [03:29] I'm poking my way through it but each step forward breaks something else. [03:29] as they can't set a pwd [03:29] because they don't have a change to save [03:29] they can't install a plugin, even though th ui lets them try [03:30] Right. yeah. I've run into that all the time. I just find a do-nothing setting to tweak. and then save. [03:30] wrt fixing it - y, i avoid configure too [03:30] y we 'just' work around our nafness, but there are plenty of people that are scared of even thinking of that kind of 'solution' [03:30] as they don't know what is a harmless hack [03:30] anyhoo, shopping [03:30] Another option might be to add a "Change password" button. still poking at it. [03:31] imo we should make it that configure presents nothing but the set/change passwd ui if passwd='' [03:31] * SvenDowideit goes - laters [04:22] SvenDowideit: That part I have working. Working through making sense of the password prompt screens which are also "confirm" screens. I think we still want the "confirm" option in some cases. [04:23] anyway - enough for tonight [04:23] *** gac410 has left [16:07] *** ChanServ sets mode: +o Babar [18:22] *** kip3f has left [20:14] *** chriswerry has left [20:17] [foswiki] foswiki pushed 1 new commit to master: http://git.io/s26Kow [20:17] [foswiki/master] Item11693: Configure needs better protection - GeorgeClark [20:17] *** GithubBot has left [20:17] http://foswiki.org/Tasks/Item11693 [ Item11693: configure lets you install an extension before you set admin pwd, then fails. ] [20:19] SvenDowideit: This commit fixes the issue by implementing password checking for all of configure. It probably needs a proposal, is too big for 1.1.5, and probably invalidates my other proposal to protect configure using .htdigest protection. [20:20] Certainly needs a lot of testing if we are going to pull it into 1.1.5. However as the "installer ships file with un-set password" problem has existed forever, I really don't see that this should be a release blocker for 1.1.5. [20:23] ArthurClemens: Probably made a bit of a mash of the trunk configure templates trying to pull together a fix for this task. With session support, we don't have to re-prompt for a password for every iteration, so added a "confirm" dialog used when a password not needed. [21:33] gac410: is this release branch? [21:33] No I only committed to trunk. [21:33] ok [21:33] I think SvenDowideit wanted the fix in Release 1.1.5, but I got too energetic. I think it's too big. Really I should create a FeatureProposal. [21:33] there have been more changes I need to look at [21:34] Yeah CDot broke the unit tests with his formfield fix [21:34] That one is more important but I didn't want to fix the test as I don't know for sure if it's the test or the formfield stuff that's broken. [23:18] [foswiki] foswiki pushed 1 new commit to master: http://git.io/J9VxAQ [23:18] [foswiki/master] Item11693: Don't check password if HTTP auth - GeorgeClark [23:18] *** GithubBot has left [23:18] http://foswiki.org/Tasks/Item11693 [ Item11693: configure lets you install an extension before you set admin pwd, then fails. ] [23:32] Reposting a question i recently asked, in case people missed it: Is there an easy way to check if a given string would be autolinked? [23:32] Without actually rendering an entire topic, i mean? [23:33] In a plugin? [23:34] Fosiki::Func::rendersomethingorother () [23:34] but, its not that simple :) [23:34] as linkage depends on web context [23:34] yeah. and User context [23:34] and on a pile of maybes that might not work just right [23:35] but i -think_ its the best general option [23:35] Hm. [23:35] SvenDowideit: Did you see my fix for your configure issue. I suspect it's way too much for 1.1.5, esp. since we have built a public release candidate. [23:35] The problem is, my AcronymDefinitionsPlugin. [23:35] its essentially intended to allow you to call a render [23:36] gac410, i get the feeling that you went overboard yes :p [23:36] flexibeast: What if user sets * Set NOAUTOLINK in their own profile. For them, *nothing* autolinks. [23:36] gac410: Remember how autolinking didn't seem to be working for me? It was because my AcronymDefinitionsPlugin was mangling things before autolinking got to it. [23:36] and i discovered last week that rendering from a non-view context means the renderer outputs something quite different [23:36] Because one of the names of our webs is an acronym. [23:37] flexibeast, nice bug :) [23:38] Yeah, good fun eh. :-) [23:39] SvenDowideit: The issue I was finding is that by the time you are down in the configure _action handlers, changing the password can be tricky. Since change has to load and save the configuration. [23:39] yay for GB networking [23:39] So i've been trying to figure out a workaround, and gac410's comment re. NOAUTOLINK is a good point which complicates things even further. :-) [23:39] gac410, y, so dno't do that :) [23:40] But you wanted any path to be able to set the password, right? [23:40] 2 other smaller choices i can think of are: 1. don't show configure ui until the pwd is set [23:40] I went that way and discovered the "initial save" broke. [23:40] 2. add a jquery link thing that says sod off to all clicks unless it is set [23:41] directing them to the set pwd ui [23:41] And as you point out we don't have a set pwd ui. You have to do a dummy change to trigger it. [23:41] hehe - that one's easy :) [23:41] set the {password} cfg to a dummy [23:42] well ... my changes do address all of your needs i think ... and then some. [23:42] tada, there's a change [23:42] y, and thus are too big for 1.1 :) [23:42] Password is not reachable via the ui. It's a hidden field. [23:42] and so is totoaly within _our_ control [23:43] * SvenDowideit recons we can do anything we like to our html :) [23:43] * gac410 was trying to avoid touching the Valuer mess that represents config variables. [23:43] i recon what you're doing is cool - i was just hoping there was a dumb hack we could do to avoid getting into a crap state [23:44] ie, we could disable the 'install extensions' button if there's no pwd [23:44] as you can't do anything useful there until [23:44] that kind of thing [23:44] yeah - though that still leaves the user wondering how to change the pw. [23:44] you've coded the real feature instead :) [23:44] blooming RM will have you head! [23:45] that's why it's not checkted into 1.1.5. (The issue has been there since 1.0.x, so I can't really see how it's suddenly urgent :P ) [23:45] its urgent because i found it and wondered if we can make a quick hack [23:45] urgency != length of time undiscovered [23:47] No - have to consider impact as well. IMHO it's "inconvenient" ... where as the "cancel saves anyway" though just as old, really rises to urgent. [23:47] who the F***K names their company something as long and unweildy as 'DistributedInformation' [23:47] hehe [23:48] anyway, let me look at my "change password" checkbox hack. that allows the "Save " button to work even without changes. Maybe that could be added. [23:48] gotta admit, i raised it expecting that i would have to do it, cos you guys have more important thing to cook [23:49] but you keep just doing - which is darned cool [23:49] i'm tempted to fly down to canberra to cancel a few ADSL connections in pharvey's street though [23:49] well, Once we hit RC status, to me, this should be the real candidate for the release and get build into final release un-changed unless a new truly urgent problem arises. [23:50] gac410, agreed [23:50] i have a few things it coulda woulda nope thankfully out of time [23:51] I've got a fix for JQUIDialog - if you have an onclick attribute set on a button it doesn't work [23:51] oh darnit [23:51] where's those selenium test systems [23:53] gac410 - should I hold off on checking it in, it could be considered as a new feature [23:54] nope :) commit to trunk [23:54] 1.1.5 is in a branch and safe from our meddling [23:54] Trunk is fine - Release11 I'd prefer that it be a truly urgent problem. Set the task as "Needs Merge" after you commit to trunk. [23:54] it's not the same as Release01x01? [23:54] but gac410 is allowed to pull your change in if :) [23:55] okey dokey [23:55] No Release01x01 is the 1.1.x branch. trunk (master) is 1.2 / 2.0 [23:55] it's been sitting on my local HD for a few months, I'd forgotten about it [23:55] really need to backup that HD [23:55] to er... github! [23:56] I have a synology disk station [23:56] what size? [23:56] but er yes, I should get on the github bandwagon [23:56] i was contemplating a 5 disk one [23:56] no ! just have one disk [23:57] but decided that was the same cost as the 3 2TB disks i still need [23:57] and thus 'did nothing' [23:57] I also have SqlGridPlugin just sitting idle [23:57] i'm at the 'when i get a week or three downtime' i need to re-do my virtualisation setup and add some serious storage [23:58] MichaelDaum never got back to me, about those changes that I needed to the JQGrid [23:58] plus i need to start thinking about the powerbill my rack is making - wakeonlan and stuff needs setting up [23:58] how many computers do you have at home [23:58] harumpf :) [23:59] or is that too personal [23:59] my workplace-home has er, um, mmm, oh dear, 15ish