#foswiki 2014-05-29,Thu

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

WhoWhatWhen
***gregg4567 has left [01:01]
GithubBot[foswiki] FoswikiBot pushed 1 new commit to master: http://git.io/bVEQ2w
foswiki/master 9bff6d2 GeorgeClark: Item12839: Use parm name suggested by MichaelDaum...
[01:13]
***GithubBot has left [01:13]
FoswikiBothttp://foswiki.org/Tasks/Item12839 [ Item12839: REST scripts should individually assert their security requirements for authorization, validation and http methods. ] [01:13]
............................................ (idle for 3h36mn)
***gac410 has left [04:49]
.......... (idle for 48mn)
ChanServ sets mode: +o CDot [05:37]
..................................................................................... (idle for 7h2mn)
MilkmanDan has quit IRC (Ping timeout: 240 seconds) [12:39]
ChanServ sets mode: +o Lynnwood [12:44]
ChanServ sets mode: +o MichaelDaum [12:57]
ChanServ sets mode: +o gac410 [13:09]
CDotSven tells me he can't pass ownership of the G+ page to me until I've been a manager for 10 days. And I can't make anyone else a manager until I am owner. Soon as I am, I'll make the association board managers, and then the clock can tick on. [13:09]
***gregg4567 has left
dgretch has left
[13:15]
timleggeHi - I seem to be getting an error on some browsers when saving. Foswiki has received a suspicious change request from your browser. I can edit in one browser (IE) on a PC but not the other (Chrome). Yesterday somoen reported the reverse [13:22]
gac410That can be caused anytime if the user uses the "back" button to return to the prior page after a post. The protection for CSRF - Cross Site Request Forgery generates a unique key for form posts to prevent them from being an attack vector. [13:24]
timleggeI did not
Just logged on and tried to edit
[13:25]
jastif you confirm the 'suspicious change request' message, what happens? [13:25]
gac410Also if the user has cookies or javascript disabled. that can cause issues. [13:26]
timleggeThere was no way to confirm on this page [13:29]
jasthm [13:29]
timleggeI don't have JS or cookies disabled [13:29]
jastIIRC there's a bug in the template if you have the validation method set to 'embedded' rather than 'strikeone'
did you change the validation method in the configuration file/page?
[13:29]
timleggelet me check [13:29]
jast(/bin/configure or lib/LocalSite.cfg) [13:30]
***ChanServ sets mode: +o SvenDowideit [13:32]
timlegge$Foswiki::cfg{Validation}{Method} = 'strikeone'; [13:32]
jast... and I just checked, that bug got fixed quite a while ago
anyway, if the 'ok'/'cancel' buttons aren't showing up, that indicates that there's an issue with the javascript
you may want to open your browser's javascript error console and see if anything bad-looking comes up when you load the/a page
[13:33]
timleggeI did install TopicInteractionPlugin recently - but this is a new install of the latest version so I just may not have noticed an issue
Uncaught ReferenceError: Behaviour is not defined
[13:34]
gac410jast, I did just confirm that embedded validation works fine on 1.1.9. And works fine trunk too. trunk.f.o had been configured as embedded for a long time. [13:35]
jastgac410: yeah, was fixed in 2011
I checked, too
hmm, I don't know what Behaviour is. I don't think it's a Foswiki core thing
[13:35]
gac410Hm. Is BehaviorContrib installed? [13:35]
timleggefoswiki/pub/System/PatternSkin/pattern.js:109 [13:35]
jastwell, that *is* kind of core :) [13:36]
timleggeNo, no Behaviour Plugin [13:38]
gac410It's a contrib.
hang on a moment.
Never mind. It's not installable. Need more coffee.
[13:38]
timlegge;-) Just poured myself a large mug [13:41]
gac410Now I'm confused. I can't find it anywhere. I'm completely mis-remembering something.
BehaviourContrib is ancient and had been removed from Foswiki.
[13:42]
timleggelooks like twisty calls it [13:44]
GithubBot[foswiki] FoswikiBot pushed 2 new commits to master: http://git.io/HlXHWg
foswiki/master cd84b8e GeorgeClark: Item12896: Make PHP flags conditional...
foswiki/master a9486ac MichaelDaum: Item12839: only create a new default for =authenticate= ... keep =http_allow= and =validate= as before...
[13:46]
***GithubBot has left [13:46]
FoswikiBothttp://foswiki.org/Tasks/Item12896 [ Item12896: pub suggested htaccess file php_flag ]
http://foswiki.org/Tasks/Item12839 [ Item12839: REST scripts should individually assert their security requirements for authorization, validation and http methods. ]
[13:46]
gac410Michael. I'm reverting your revert. See the original proposal. Comment From 2 Apr 2014. It was indeed to apply secure defaults to ALL THREE.
It was in the initial commit including the example EmptyPlugin showing all three.
[13:48]
MichaelDaumwait a sec
let us talk this thru before stressing svn too much
will you, gac410 ?
[13:49]
gac410timlegge: I agree twisty is calling behavior. I have no idea why. Maybe for backwards compat to 1.0.9
yeah. But this was indeed proposed and talked about.
[13:49]
MichaelDaumcould you pleae point me to proposal where that is as I can't find it. [13:50]
gac410you may have missed it but it was there. Really. [13:50]
MichaelDaumall I see is that all rest handlers were broken this morning [13:50]
***ChanServ sets mode: +o Lynnwood_ [13:50]
TarboxI've got twisty. Use it heavily, no problems. Maybe upgrade/reinstall? [13:50]
gac410MichaelDaum: http://foswiki.org/Development/AllowGuestsToUseRESTAsDefault "Plans to resolve this. 02 Apr 2014
authenticate default to TRUE validate default to TRUE http_allow default to POST
[13:51]
TarboxMichaelDaum, is it NatSkin that's turned all the tables to have alternating grey/white backgrounds for the rows, or Foswiki itself? [13:52]
gac410In order to improve backwards compatibility, add an EXPERT configuration option under the Security & Authentication / Environment tab: {DefaultInsecureREST} = 'FALSE'; Enable this setting to restore the pre-1.2 defaults.
Tarbox. That's part of Foswiki css. iirc
[13:52]
TarboxWoot.
css is good.
[13:53]
MichaelDaumgac410, it never occurred to me that we extended "allow guests to use rest" to cover http_allow and validate as well ... I can't see why we need this in the scope of this proposal and in general
gac410, could you please explain why we now alter http_allow and validate as well, please.
[13:54]
gac410Once guests can use it our default rest protection in general should be secure. All 3 contribut to good rest security. [13:55]
MichaelDaumfor instance, why require POST by default?
that sounds very uncommon
[13:56]
gac410Because there is no way for core to know if the handler will update. So defaulting to validation and post is good practice. The author can easily lift the restriction. [13:57]
MichaelDaumI rarely have any need to POST [13:57]
gac410It was all right there in the example code from the start. So your rest handlers don't update? [13:58]
MichaelDaummost is fetching info. so a GET is sufficient [13:58]
gac410Right. But core cannot read your mind.
Default is not for coding convenience. It's to protect foswiki core.
[13:58]
MichaelDaumwould you say even 1.1.9 practice for authenticated users calling REST was insecure already? [13:59]
gac410I apologize I should have said somethng when I noticed your checkins were only setting / clearing auth flag and ignoring the other two. [13:59]
MichaelDaumyea [13:59]
gac410If rest handlers were updating and not needing POST then yes. I found default extensions that were indeed open that way, also updating without validation. [14:00]
MichaelDaumI was working under the impression of allowing guest to call rest ... which is only about authentication status ... not so much about GET .vs POST and strikeone validation and stuff.
validation: do we need it to default to 1 even when disabled in LocalSite.cfg?
[14:00]
gac410Hm... I don't think so. If it does, It's a bug. I think I found / fixed that one.
UI::Rest should only run the validation checks if it's enabled in core.
[14:02]
MichaelDaumthe only plugin I ever used requiring validation in its rest handler was AntiWikiSpam ... and the call failed when validation was set to none throwing an invalid validation exeption ... [14:03]
gac410Yeah. Sven fixed that in AWSPI, but I fixed it better in UI::Rest [14:04]
MichaelDaumah ok
good
so what do we do now?
we obviously can't close this task yet
[14:04]
gac410Indeed Foswiki::UI::Rest. if ( $record->{validate} && $Foswiki::cfg{Validation}{Method} ne 'none' && !$session->inContext('command_line') ) [14:05]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::UI::Rest [14:05]
MichaelDaumlots of plugins need to be reviewed yet again. lots. [14:05]
gac410yeah. That's why I ran trunk with InsecureREST enabled for so long.
And added the diagnostics to list the rest handlers.
[14:06]
MichaelDaumit only was okay because I never defined InsecureREST to be either true or false ... and thus these defaults never where applied ... a result of a double negotiation boolean implemented the wrong way around [14:07]
gac410We could flip that flag back to EnableLegacyREST (or whatever it was you suggested :) )
That would give everyone time. And also bring it up at our release meeting. (BTW silence has been deafening .. no idea if anyone will show)
[14:07]
MichaelDaumboth LegacyRESTSecurity and EnableLegacyREST is okay as long as there is no negotiation in the name of a boolean flag [14:08]
gac410I made it your suggestion which was fine. I just can't remeber now and am too lazy to go look :D [14:09]
MichaelDaumokay then let's move forward
I've got a better understanding now of what you are trying to do
[14:09]
gac410Would it help if the Rest handler diagnostics made the Undef a bit more visible. [14:10]
MichaelDaumdunno
cosmetics
[14:10]
gac410If I hadn't actually found issues, then you'd have a better chance of convincing me :) [14:10]
MichaelDaumwhat we need now is that every rest handler fully decides on the three settings
right?
if so, we can create log warnigns if one of the three is undefined in registerRESTHandler
[14:11]
gac410Yes. And cosmetics, the description might be helpful for an admin asking what does this do. [14:11]
MichaelDaumto give users a way to quality-check plugins they installed [14:12]
gac410Yes. but warnings are really noisy, which is why I added the details to the InstalledPlugins page. [14:12]
MichaelDaumbetter noisy than forgetting a single insecure plugin [14:13]
gac410Do you want warnings for every hit to every rest handler, or just check InstalledPlugins undef. That's why I suggested making it more visible. [14:13]
MichaelDaumjava is noisy. let's make perl noisy as well ;)
InstalledPlugins is such a mess atm: info about a single plugin is scattered all over the page.
[14:13]
gac410Okay. Warn if legacyREST is enabled, and setting is undef. Otherwise they'll find out soon enough. :) [14:14]
MichaelDaumwarning if LegacyREST is disabled _and_ a rest handler was registered without specifying the full security profile
one may argue to even reject registration without a full security profile as well
[14:15]
gac410Hm. so it's not okay to just let a handler default to POST / validate. We want dev to always be explicit? [14:16]
MichaelDaumthats the consequence
isnt it
[14:16]
gac410Well, rest handlers that update via post with validation can just take the defaults. [14:17]
MichaelDaumwhether the system is secure or not depends on LegacyREST then ... as defaults might change depending on its value ... which btw I don't like at all ... conditional defaults
defaults are things hardcoded as a last resort
[14:18]
gac410Yeah. But when the defaults change in a minor release, admin needs some way around, espec. if 3rd party or local / consultant developed plugins use the old model.
Otherwise they can't upgrade.
[14:19]
MichaelDaumchanging defaults is adding a needless point of failure when users need to switch it on or of for a single old plugin to make it work ... yet risking security for other plugins that relied on "new defaults" [14:20]
gac410Okay. So warn if "full profile" is not set during register. I still think we need to treat this like a deprecation. Give sites a chance to upgrade without major pain. [14:21]
MichaelDaumtwo things to consider: either (1) remove LegacyRESTSecurity and implement new hard-coded defaults or (2) require plugins to fully specify all three security parameters and issue a warning if they don't [14:22]
gac410Okay. Document LegacyREST has been deprecated. You can enable it in 1.2, it goes away in 2.0, And warn if all 3 parameters are not specified, regardless of LegacyREST setting. [14:23]
MichaelDaumWARNING: your rest handler does not specify http_allow, validate and/or authenticate ... proper operation depends on default values in the core system. these may be different depending on the {LegacyRESTSecurity} setting
do you get the SMELL?
I don't like to do this wrong now, wait another year for 2.0 to materialize and put users in a bad situation in the meantime
[14:23]
gac410yeah. But we are remodeling a airplane in flight. Rather have some smell than a crash. Lets bring it up at the release meeting. If anyone shows. [14:25]
MichaelDaumok fine [14:26]
TarboxHey guys! Could you recommend virtual machine settings for a low load server? [14:30]
gac410WARNING: your rest handler does not specify http_allow, validate and/or authenticate. LegacyRESTSecurity is enabled. This handler may be insecure and should be examined.
vs: WARNING: your rest handler does not specify http_allow, validate and/or authenticate. These settings have been defaulted to be secure.
[14:31]
TarboxFoswiki has chosen secure defaults. [14:35]
gac410timlegge: Back to your issue. Sorry, we got sidetracked a bit. Although the Twisty code references behavior.js, at least on foswiki.org ( 1.1.9 ) it doesn't generate any js warnings.
Do you have any issues with strikeone on foswiki.org, say updating in the Sandbox web?
MichaelDaum: Do you do anything with Twisty? pub/System/TwistyPlugin/twisty.uncompressed.js has references to behaviour.js and BehaviourContrib which is long gone.
[14:36]
MichaelDaumthis code isn't used anymore. it is only there for backwards compatibility in skins
we can actually remove it and change TwistyPlugin::_addHeader to only use the jquery.twisty.js implementation
DEPENDENCIES already says JQueryPlugin is required
so no reason to try to make it work without nowadays
even more so as BehaviourContrib is gone
[14:41]
gac410Okay. just trying to figure out why timlegge is getting errors: Uncaught ReferenceError: Behaviour is not defined
Maybe a skin issue then. He also is getting strikeone validation messages.
[14:44]
MichaelDaumno BehaviourContrib installed it seems [14:45]
gac410No BehaviourContrib even exists. [14:45]
MichaelDaumit is there in svn over here ... last time I looked [14:45]
gac410okay yeah its there.
Hm. It's in the extensions web too. Why didn't it pop up in configure extensions installer. In any event, it should not be installed on 1.1.9. He's got other iissues I suspect.
Ah. timlegge: Check your bin/configure. Make sure that your jquery version selected under Extensions -> JQueryPlugin settings actually exists.
[14:45]
.... (idle for 19mn)
TarboxCan any of you guys comment on virtual machine settings for a low load server? In general is fine. Do we just reserve memory for it so it doesn't cache out in between requests, or is there anything else? [15:06]
jastthat's the most important thing, definitely [15:08]
gac410Tarbox, At least for me, I have no idea. My last experience was an IT group that insisted on overcommitting their server. IIRC another issue was using Network storage. Too much latency. [15:08]
TarboxAny idea how much? [15:08]
jastthe thing is, the wikis I set up usually run a bunch of other things, too, such as Solr (with SolrPlugin)
we've got those to run decently with about 1 GB RAM
you can probably shave off a bit if you don't use stuff like Solr
[15:09]
TarboxWe use solr. :P [15:09]
jastokay, 1 GB should be your baseline then IMO
might want to consider making two cores available, too
[15:09]
TarboxAnything else? I/O was mentioned when we were talking about it yesterday, but I'm not sure what cna be tweaked there. [15:11]
jastCPU can be an issue if you have complex stuff running in loops
the way to tweak I/O is to have lower-latency storage or less activity from other things on the same hardware :)
nothing much else you can do
[15:11]
gac410And lots of memory for buffering? [15:12]
jastRAM for caching will always help, though [15:12]
gac410yeah that too :) [15:12]
jastand now I'll try and get the house cleaned up a bit... fun times [15:12]
gac410Something to look into Tarbox https://communities.vmware.com/message/1849547 If vmware is stealing your memory then it's going to hurt. [15:15]
TarboxThank you.
MichaelDaum, the More menu in %USERACTIONS doesn't seem to work, even with the stuff you posted yesterday.
[15:17]
MichaelDaum"doesn't work" ... I like these bug reports ;) [15:19]
TarboxI'm never sure if I have your attention. :P The More shows up, and highlights if you hover, but the menu itself never pops up, neither on its own or after clicking it.
Also, it's colored black when the non-menu items hav emorphed into blue. Probably not relevant.
[15:20]
MichaelDaumany local modifications?
the menu is activated in natskin.js
[15:22]
TarboxI have custom actions that I coded similarly to More. They exhibit the same behavior, including the blue/black text. They don't show up on every page, but even when only More is on a page it doesn't do right. [15:23]
MichaelDaum<strike>activate</strike> ... initialized
see initTopicActions()
[15:23]
TarboxI have a custom action that isn't a menu, it shows up in blue like the other non menu actions, and works fine. [15:24]
MichaelDaumafter initialization the natMoreActionsMenu receives the class natInitedMoreActionsMenu
have a look if that's the case
... using firebug / dev-tools ... not the html sources
[15:24]
TarboxIt is indeede missing.
Maybe a superfish problem? I hate guessing.
[15:25]
MichaelDaumeither initTopicActions() is never called, or the class .natMoreActionsMenu was not found in the DOM ... which might indicate a HTML markup error.
try this on the console: jQuery(".natMoreActionsMenu")
[15:30]
Tarboxoh lord I didn't know I could do that.
three objects.
which is how many I have.
[15:31]
MichaelDaumI've got one [15:32]
TarboxI have custom menus [15:32]
MichaelDaumjQuery(".natMoreActionsMenu").length returns 3 ? [15:32]
Tarboxyes
hold on
[15:33]
MichaelDaumplease remove the other two and try again [15:33]
TarboxJust did.
Still no.
[15:33]
timleggegac410: JQueryPlugin is enabled [15:33]
MichaelDaumjQuery(".natInitedMoreActionsMenu").length ? [15:34]
TarboxWhat version of jquery is it set to use?
1
[15:34]
gac410Tarbox, depending on when you grabbed trunk from svn, make sure InsecureREST or LegacyRESTSecurity are ENABLED in configure / Security / login tab. [15:34]
Tarboxenabled [15:35]
MichaelDaumTarbox, try jQuery(".natMoreActionsMenu.sf-js-enabled").length [15:36]
gac410timlegge: bin/configure Extensions -> {JQueryPlugin}{JQueryVersion} What version is selected. And if you click the dropdown, is that one of the available versions. On 1.1.9 it should be Jquery-1.8.3 iirc [15:36]
timleggeTarbox: My current VM has Intel(R) Xeon(R) CPU X5650 @ 2.67GHz and 4 GB of ram. It seems acceptable for the small number of users that I currently have and a lot more responsive than previous server [15:37]
TarboxMichaelDaum, 0 [15:38]
MichaelDaumthen your menu still isn't initialized by superfish [15:38]
timleggegac410: jquery-1.8.3 [15:38]
MichaelDaumtimlegge, there is something fishy about your natskin.js not calling initTopicActions()
timlegge, I mean Tarbox
[15:39]
gac410timlegge: Has anything changed for the browser that might be blocking js? Recent NoScript update? etc. Do you get that javascript error on http://foswiki.org/Sandbox And can you edit there without strikeone errors? [15:40]
TarboxI'm enabling some debug. [15:41]
gac410MichaelDaum: Want me to change the default for LegacyRESTSecurity again so I don't knock you down when I reapply the defaults? I've added two warnings if any defaults are applied, depending upon the setting of LegacyREST [15:42]
MichaelDaumgac410, nono just revert my revert. I'll have to deal with the mess over here afterwards. [15:43]
gac410One warning: | 2014-05-29T15:30:27Z warning | WARNING: your rest handler does not specify http_allow, validate and/or authenticate. Foswiki has chosen secure defaults: | JQueryPlugin/tmpl -
or 'WARNING: your rest handler does not specify http_allow, validate and/or authenticate. LegacyRESTSecurity is enabled. This handler may be insecure and should be examined:';
[15:43]
Tarbox( -.-)\ It's the fault of an error I've been ignoring because ti didn't look relevant.
TypeError: q.autosuggest is not a function
init on load crashes out and doesn't get farther than that.
[15:44]
timleggegac410: Thats weird I just did a graceful restart of apache and I don't see the issue anymore. I am not sure if some session timed out. Any idea if there are issues having multiple browsers logged in on the same laptop with LDAP? [15:49]
MichaelDaumTarbox, ah ok. now you got me. [15:51]
Tarboxif (foswiki.getPreference("NatSkin.initAutoComplete")) {
initSearchBox();
}
I'm perfectly happy disabling auto complete.
not sure where though.
[15:51]
MichaelDaum... as you don't seem to have installed SolrPlugin yet [15:51]
Tarbox... search works.
uses solr
I'm sure because %HOTTOPIC% kept crashing utnil I fixed it.
[15:52]
MichaelDaumwhich version of SolrPlugin do you have? [15:52]
Tarboxah
I see.
[15:52]
gac410timlegge: The foswiki strikeone key is generated for the session. If you have multiple browsers sharing the same session, then one might expire the key that the other is using. [15:53]
Tarbox1.10
If you say upgrade I may cry. It took hours to get solr to work the first time. Interleaved versions or something.
[15:54]
MichaelDaumTarbox, autosuggest comes from pub/System/SolrPlugin/jquery.autosuggest.js ... which your version of SolrPlugin might not have yet. Consider upgrading.
in any case you definitely found an error in NatSkin
[15:55]
TarboxI don't suppose you recall off hand if 2.10 and 1.10 use the same version of solr? [15:56]
MichaelDaumSolrPlugin 2.x is a lot more modern in many respects ... last not least using a 4.x solr ... which was 1.3 before [15:57]
gac410Ah... MichaelDaum. Last night was a Task Triage evening. LOTS of tasks are sitting in New state, some you are working on, Could you do me a favor and review your Nat, jquery, etc. tasks at some point and flip them to either Confirmed, or WorkedOn
Triage gets difficult with 100's of tasks in the New Tasks list.
[15:57]
MichaelDaumyes seen that. thanks. will do. probably not today anymore. [15:58]
gac410We all need to do a better job of getting tasks out of "new" status and assigning a component if missing. Our tasks web is really a mess right now. [15:58]
TarboxI appear to be on solr 4.3.0 [15:58]
MichaelDaumTarbox, and your SolrPlugin? [15:58]
Tarbox1.10 [15:59]
gac410I went back 100 Items last night trying to confirm what I could. And I think I found some that are actually fixed, so I closed them. [15:59]
MichaelDaumTarbox, to immediately cure the NatSkin error, go to templates/javascript.nat.tmpl and disable initAutoComplete using %TMPL:DEF{"initAutoComplete"}%'NatSkin.initAutoComplete': false,%TMPL:END%
then consider upgrading SolrPlugin and switch it back to the original value
[16:01]
Tarboxthank you. [16:02]
MichaelDaumwhich was %IF{"context SolrPluginEnabled" then="true" else="false"}% ...
what would the installer do when NatSkin is installed and when it sees an Optional dependency on SolrPlugin >= 2.10 ... but finds a SolrPlugin-1.x?
[16:02]
gac410Reminder a Release meeting will be held Monday 6/2, 1300Z to figure out how to get 1.2 out the door. We'll meet 1st and 3rd Monday of each month in #foswiki-release
MichaelDaum: Optional dependency. It should warn but not auto-install it. Only Required deps are auto-resolved.
[16:05]
MichaelDaumhm. so I can't express "you got SolrPlugin installed but this one is incompatible with NatSkin. please upgrade to version x" ? [16:06]
gac410Hm.... I don't think so. Maybe a custom checker in configure? [16:14]
MichaelDaumgood idea [16:14]
gac410Our dependencies code is really minimal.
Usually I anchor that on the Enable checker for the plugin that has the dependency
Er... Except Skins don't have enable. NatSkinPlugin maybe?
[16:14]
MichaelDaumy [16:15]
CDotMichaelDaum: you're editing under me? [16:19]
MichaelDaumnot that I know
just normal edit as in edit-save-run-away
[16:19]
CDothmmm. ReleasePlanDiscussions - just said it merged an edit (and lost my changes :-( ) [16:20]
gac410Crap.... That was me. [16:20]
CDotok, I didn't realised it was being worked on, I'll back off. [16:20]
gac410Nonn... not me [16:20]
MichaelDaumI removed some natedit related comments [16:21]
gac410I did not do that. I was editing ReleaseMeetingsTemplates [16:21]
MichaelDaumbut there was no lock in place [16:21]
gac410Maybe CDot used the back button after save? [16:21]
CDotyes, I did - I was editing the format
not a problem, so long as I know what happened.
[16:22]
gac410Too bad the back button couldn;t drive some js that either re-acquires the lock or warns if another edit started. [16:23]
CDotYeah. It can't. [16:25]
TarboxBut you can commandeer the page the back button takes you to.
Or at least I thought I'd seen that...
Ah it's HTML5.
[16:26]
CDoteven then, the problem is you are going 'back' to an edit page; so it's key that you don't reload a different page, because the transitory edit data in the browser input fields would be lost.
What you really want is an even in JS to tell you when the back button has been hit, in the page being 'backed' to.
[16:35]
TarboxHeh. I should know better than to challenge you guys. [16:35]
CDotTarbox: it's never a challenge; intelligent questions are *always* welcome, as are ideas [16:36]
TarboxWhat *is* the state of javascript between pages? Does it pause/resume? [16:36]
CDotdumb questions and stupid ideas, however....... ;-)
JS is event driven, so whatever JS is associated with the "curent" page receives the events
[16:36]
TarboxSo if you do a timed event... gosh I forget the funciton name, hit forward, then back, you lose the timed event? Or does the event run on the following page? That last one cannot be possible. [16:38]
CDotso you could see it as "pause/resume"
no, events are targeted at elements, which are per page
[16:38]
TarboxsetTimeout
you setTimeout for 2 seconds, click a link, go forward, hit back... do you still get a timeout?
seems like a lot would break otherwise.
[16:38]
CDotno, because it's bound to an element (a function) in a page that isn't current [16:39]
Tarboxand the timer stops?
while on other pages?
[16:39]
CDotof, sorry, if you went out and back then i guess, yes, you would
CDot has never tried it
[16:39]
Tarboxsave current time. Set timeout for 5 seconds. Check current time. If current time is not saved time + 5 seconds, your timeout was suspended.
ugly
probably have to be desperate.
[16:40]
CDotyou would, yes :-) [16:40]
CDot sees there's a JS library that emulates onhashchange on non-HTML5 browsers, using the time approach (ish) that Tarbox proposes, so it *could* be done, I guess. [16:45]
MichaelDaumgotta go. tomorrows. [16:51]
gac410Hm... just missed him. NatEdit Settings tab, doesn't seem to have any way to add new settings. I just has a Topic Parent box. [16:52]
TarboxSo the flaw here is save a page, hit back, save a page again? Could you flag the save button when it's hit? Maybe iwth the time it was hit. Then if they hit it again you know they've hit it before, and can pass the time they hit it on to foswiki to check for whatever's been done in the meantime. Then they can hit forward and back all they want?
Foswiki can even compare the time a button was claimed to have been hit against known edits.
[16:58]
CDotTarbox: it's not a flaw, per se. It's a bit of a PITA, but confirming the resubmission is not such a big deal. But if you want to "fix" it, go right ahead. [17:05]
TarboxIt's not that important to me.
Som eproblems intrigue me
my mind won't let them go.
It doesn't seem to care how important it is/isn't
[17:05]
CDotah, that's often the problem :-)
Only one solution; get out of your mind.
[17:05]
Tarboxtalking it out helps. Otherwise they just echo in my head forever.
Thanks for listening to me.
[17:08]
CDotany time. And any time you want to help, just pick a problem - there are more than enough to go around! [17:10]
gac410CDot Yesterday I added the "Status" to the task query in ReleasePlanDiscussion. And was impressed with the number of resolved tasks from back when pharvey created the list. [17:11]
CDoty, we done good
no idea how many other issues should be on that list that aren't, though
[17:12]
gac410Yeah that's why I started the triage of new tasks yesterday, but there is LOTS of noise. sigh.
I think a lot will pop out once we get an alpha / beta cycle going. Though it depends upon people actually testing. It's been real thin at times.
[17:13]
CDotit has, several times I've been triaging other issues, and I've been stalled by other things found along the way
the unit tests are a massive help, but only for those bits they actually test :-(
[17:15]
gac410yeah. It still amazes me how much the tests have grown, And how much they miss.
We need tests for %SET. Sven threatened to revert the new feature if tests were not added. But the task got set WaitingForRelease anyway. :P
[17:16]
CDotCDot has never been a fan
BTW the currently failing unit test; does not fail on my platform
CDot has concluded it's a CPAN module version, in Encode or i18N somewhere
[17:17]
gac410They fail for me. But I don't really understand the issue. It might be system locale related as well.
Another little thing we need to do is review all the Expect Failure failures. Some might be things we need to fix.
[17:19]
CDotit's an encoding issue. It may be to do with a lack of control over the CharSet in the test itself, but because they don't fail for me, I can't pin it down.
CDot has tried
[17:22]
gac410The $20,000 question. How would it manifest in a real topic. Since fsfs and I both have failures, is there a way to see if it would cause breakage. [17:25]
CDotthe failure is *not* a failure. It's simply a different encoding of the same character.
mind you, it's a failure if the encoding of the output page doesn't match the encoding of the character, I suppose
CDot didn;t check that
[17:30]
GithubBot[foswiki] FoswikiBot pushed 1 new commit to master: http://git.io/JZH4gQ
foswiki/master eff0607 GeorgeClark: Item12839: Revert back to more secure REST defaults...
[17:45]
***GithubBot has left [17:45]
FoswikiBothttp://foswiki.org/Tasks/Item12839 [ Item12839: REST scripts should individually assert their security requirements for authorization, validation and http methods. ] [17:45]
gac410Okay... the revert wars lob it back .. Back to MichaelDaum :D (actually, for the lurkers, I think we're in agreement. not much of a war here. Maybe a light skirmish )
And that finishes me for the afternoon. AFK
[17:46]
.................................... (idle for 2h58mn)
GithubBot[foswiki] FoswikiBot pushed 1 new commit to master: http://git.io/tJObyg
foswiki/master c4c79db GeorgeClark: Item12839: Update rest authority for EditRowPlugin...
[20:45]
FoswikiBothttp://foswiki.org/Tasks/Item12839 [ Item12839: REST scripts should individually assert their security requirements for authorization, validation and http methods. ] [20:45]
***GithubBot has left [20:45]

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