#foswiki 2017-01-08,Sun

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

WhoWhatWhen
***ChanServ sets mode: +o Lynnwood [03:16]
............ (idle for 56mn)
FoswikiOnSlack has quit IRC (Remote host closed the connection) [04:12]
.......................................... (idle for 3h29mn)
ChanServ sets mode: +o cdot [07:41]
.............. (idle for 1h9mn)
GuilainC_away is now known as GuilainC [08:50]
.................... (idle for 1h36mn)
Lavr has quit IRC (Ping timeout: 258 seconds)
ChanServ sets mode: +o Lavr
[10:26]
.......................................... (idle for 3h29mn)
warbleWhere does the "Does NOT work on Foswiki 1.0 any longer." on https://foswiki.org/Extensions/ActionTrackerPlugin come from?
does the author just type those letters in the box?
[13:56]
.................. (idle for 1h27mn)
***ChanServ sets mode: +o gac410 [15:24]
gac410warble: It's a message typed into the Extension form on the topic in the Extensions web. [15:25]
............... (idle for 1h11mn)
warbleoh my [16:36]
gac410: is there a toggle from "edit wiki sauce" back to TinyMCE? [16:43]
jesuisseIs someone here?
I've got a really strange problem with the QUERY macro.
I have a topic with an author field like "Pq8k_foIg" (I know, weird username, but bear with me...)
%USERNAME% resolves correctly to "Pq8k_folg"
%QUERY{"info.author"}% produces "Pq8k_5ffoIg"
The inserted 5f is the hexadecimal encoding for the underscore. Can someone tell my why this is happening?
And whether it's a bug or a feature?
[16:53]
..... (idle for 21mn)
gac410jesuisse: this gets into "cUID" encoding of the wikiname / username. Underscore it not allowed as it's a "special character" used to encode non-ascii characters. That said, there is something wrong as you should not see that unless you look into the raw topic
We have 3 identities. WikiName, login name, and the cUID (canonical userid). The latter is encoded to support characters that would be illegal to things like the underlying rcs system.
[17:17]
jesuisseyep, I encountered that a while ago.
So, if I understand correctly, _ is a no go but if I replace _ with -, I should be fine?
[17:18]
gac410There are some problems in that area, but it's outside of areas where I work on foswiki, so I'm not really able to address them.
Well, in theory, the _ should get "protected as the _5f and then converted back. But obviously something is going wrong.
[17:19]
jesuisseWell, what might be wrong is some of my code in OpenIDConnectLogin :-) [17:20]
gac410That whole area is the target of some proposals to redesign it, but really needs a motivated developer to tackle the issues. It's really complex especially due to 3rd party authenticators, and anarchic backends like rcs.
In some instances currently the code can't determine if it's working with a cUID (which needs decoding) vs. a wikiname or login name, which does not.
It was a design flaw many many years ago
[17:20]
jesuisseI'll try to replace _ with - and see if I can get around the problem. _ is part of the user name as provided by some OpenID providers... [17:22]
gac410warble, unfortunately I don't believe that there is a way back from wikitext to wysiwyg with the new natedit. The original text editor did have a way back.
jesuisse: It could also be that the user name from OpenID should be being encoded to "protect" the _ as it's special.
[17:23]
jesuisseYes, I thought something like that might be the problem.
But like you said, somewhere there seems to be an additional problem because I get to see the wrong string.
[17:24]
gac410y, The problem with substituting -, is that if it ends up in the WikiName, it won't autolink. :(
I think iirc, that _ is acceptable for autolinking wikiwords, but maybe not. I just don't remember.
[17:26]
jesuisseJust checked; the raw author data in the topic txt file is wrong already, so the problem really is when storing the username into the store. [17:27]
gac410warble: I'm wrong. There is an icon on the toolbar that returns to wysiwyg
Its the circular arrows next to the last icon - the wrench. Hover over it and it says "switch to wysiwyg"
[17:29]
warbleOh, it's the refresh icon lol [17:30]
jesuisseOkay, I now substitute _ with - before passing the username on to the foswiki internals, so this is a workaround for now. [17:34]
Oops - no. Storing - doesn't work either.
The hyphen now gets encoded to _2d in the store, but the query macro doesn't decode this, and neither does anything else that accesses the author info of the topic (USERINFO, SEARCH with type=query etc..). Looks like a bug to me.
I don't think I can fix that by encoding the username myself, because this will just lead to the storage code double-encoding, since my encoded string will need to contain the underscore.
[17:40]
gac410If it's detected as _[0-9A-Fa-f] then it might get decoded.
I've looked for open tasks, and am not finding any, but might be mis-categorized too.
jast and MichaelDaum probably know this area best ... using external authenticators. Maybe cdot too.
[17:46]
jesuisseSeems to me this is larger than external authenticators. There is an asymmetry when storing and loading the author field from storage.
The data gets encoded upon storage and doesn't get decoded when reading it back out.
[17:48]
gac410It may be more of a mapping issue than a decoding. The cUID stored in the field should be mapped to the WikiName. But I agree, it does sound like the bug is either in QUERY or DataForms somewhere.
No .. I'll amend that, A QUERY bug not dataforms. info,author should be decoded consistently as %USERNAME% macro. (or %WIKINAME%) not sure.
[17:55]
jesuisse%USERNAME%
(at least that's how it behaved when I used LDAP usernames)
[17:57]
gac410:( It's not actually documented as what it returns.
Does QUERY and SEARCH (type=query) behave the same?
[18:00]
jesuisseyes, both fail
also, USERINFO fails, too - it can't turn an underscore-username into a wikiname at all.
[18:01]
gac410Okay. If you could please open a task. We have a release meeting tomorrow (1300Z) and I can raise visibility a bit then. Hopefully if the right people show up ;D [18:02]
jesuisseok, will do [18:02]
gac410I'm not sure I can target that to 2.1.3 - dickering around internal to query / search is probably too high risk - at least for me to touch. [18:03]
jesuisseit's not that important - I'll simply remove all special characters from usernames before passing them to foswiki. But I think it should be on someone's radar. [18:03]
gac410y. And in the event that it gets fixed, you might want to make "remove specials from usernames" a configurable option, [18:04]
jesuissegood idea :-) [18:04]
gac410jesuisse: the code documents "author" as the "canonical User ID" or cUID.
Can you try using something like %USERINFO{ info.author format="$wikiname"}% ( I'm not sure of the syntax to insert the info.author into that macro)
Note that $username is documented as hidden to non-admins. I have no idea why though as WikiUsers would reveal it.
If its inside a search results you might need something like format="$dollarwikiname" ... to prevent search from inserting the current user's wikiname.
To be consistent with the tokens used for queries against "rev 1" the fix might be to add info.wikiname info.wikiusername and info.username to decode the info.author field.
Note that this is all part of the Foswiki::Meta module which processes all of the topicinfo
[18:12]
FoswikiBothttps://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Meta [18:21]
.... (idle for 15mn)
jesuissesorry, I'm busy right now. Back in an hour... [18:36]
............................................ (idle for 3h37mn)
***GuilainC is now known as GuilainC_away [22:13]

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