« Login/Register Feature
These two bytes may not matter to you...
Need some help on a UI matter »

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: These two bytes may not matter to you...
« Reply #90, on September 9th, 2011, 03:38 PM »
Re: elite club, we're in agreement... Considering I never understood layers even when working on AeMe (in which they were used by Dragooon, who certainly understood them :P), I'm sure most modders are like me.
Because I analyzed thoroughly index.template.php when I started working on SMF years ago, I can safely say that if a feature is very prominent there, and documented somewhere, it's bound to be better noticed. Which is why I wanted the index template to have a fallback $context['skeleton'], *not* the Wine skin (which would have made more sense, as it is.) I may change my mind later but that's what I though ;)

And it's documented in Warm/skin.xml (which is where I put all of the comments really...), and in the Load and Subs files (hopefully.)

Re: macros, I made the change this morning -- I'm not surprised it was so quick to do. I still have to start work on converting loadSubTemplate() to loadBlock(), but since I do everything manually to avoid errors, this one will be longer... :P

Re: pimp, actually the French 'official' word for pimp is proxénète, and the common word is maquereau (mackerel -- a pimp woman used to be called 'mère maquerelle' a century ago), often shortened to just 'mac'. 'Maquereau' is pronounced exactly the same as 'macro' (the 'r' is pronounced, of course.)

Okay, another one...

I thought long ago of getting rid of all the sSessionId etc in JavaScript and replacing them with a global variable that we'd set up on every page. I don't see any reason for not doing it -- security-wise, it's exactly the same as putting the variables into a function parameter, really... I just wanted to post about the fact that I'm working on it right now -- if you have any issues with this, please get back to me ASAP so that I can revert my work before I commit it ;)

PantsManUK

  • [me=PantsManUK]would dearly love to dump SMF 1.X at this juncture...[/me]
  • Posts: 174
Re: These two bytes may not matter to you...
« Reply #91, on September 9th, 2011, 03:48 PM »
Quote from Nao on September 9th, 2011, 03:38 PM
Re: pimp, actually the French 'official' word for pimp is proxénète, and the common word is maquereau (mackerel -- a pimp woman used to be called 'mère maquerelle' a century ago), often shortened to just 'mac'. 'Maquereau' is pronounced exactly the same as 'macro' (the 'r' is pronounced, of course.)
In my (admittedly poor, barely school boy) French, phonetically speaking 'maquereau' is pronounced 'ma ker oh'. I defer to you msr, given it's your language and all ;)
« What is this thing you hoomans call "Facebook"? »

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: These two bytes may not matter to you...
« Reply #92, on September 9th, 2011, 03:49 PM »
Well, any place it's accessible from the script is a problem, of course, and making it directly more accessible from the page if it's compromised isn't particularly clever - but at the same time, it's really not an issue because any place that it's *currently* actually used, you can query for the session ID anyway.

All the objects that currently require a session ID are all fed it, they're passed an object going in, which is stored into the object itself - like when a new instance of weToggle is created, one of the parameters given to it is the session, but it's then stored in this.opt. So when you create a new instance of it, you can refer to that object's .opt and get the session, and since there's a weToggle that uses the session on every page for the header...

There isn't really a good method of avoiding it, unfortunately. Either we don't have it and open ourselves up to CSRF type deals, or we do and risk session stealing.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: These two bytes may not matter to you...
« Reply #93, on September 9th, 2011, 04:01 PM »
@PantsMan> In oral French, 'que' is pronounced like a 'c' (or 'k'), except for the word 'que' itself, where you pronounce the 'e' (as in 'linger'). It's a mute 'e', basically. So maquereau is pronounced mah-crow. ma-q-ro.
Quote from Arantor on September 9th, 2011, 03:49 PM
Well, any place it's accessible from the script is a problem, of course, and making it directly more accessible from the page if it's compromised isn't particularly clever - but at the same time, it's really not an issue because any place that it's *currently* actually used, you can query for the session ID anyway.
Yeah...
Quote
All the objects that currently require a session ID are all fed it, they're passed an object going in, which is stored into the object itself - like when a new instance of weToggle is created, one of the parameters given to it is the session, but it's then stored in this.opt. So when you create a new instance of it, you can refer to that object's .opt and get the session, and since there's a weToggle that uses the session on every page for the header...
That's where it's silly. The weToggle on all pages. I wouldn't do without it, especially if forum owners are going to use the header to put a 1024x768 div, or a naked picture of Susan Boyle...
Quote
There isn't really a good method of avoiding it, unfortunately. Either we don't have it and open ourselves up to CSRF type deals, or we do and risk session stealing.
I'd rather take the latter. As of now, putting sSessionVar into a we_* variable increases risks by zero percent. Unless of course someone releases a theme where the toggler is disabled... But then, they'd also have to remove the toggle from the homepage's board info center (not that it's a vital toggler though... Might as well remove it), remove quick edit, quick reply and things like that... And even then, there are still plenty of 'hidden' inputs on the page with the session stuff in plain view.

What would you rather have? Eh...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: These two bytes may not matter to you...
« Reply #94, on September 9th, 2011, 04:17 PM »
Quote
What would you rather have? Eh...
Well... session stealing is still possible even without that. To remove the risk, you have to remove it from every place it's used. It's in forms, it's in links, and if you remove it from all of those, that IS a security risk in itself because the only security then is in the cookie - and cross site scripting will have a field day.

tl:dr; It's the lesser of two evils, but I think having it in the page less will be beneficial overall, it's certainly no less secure in the long run than where we are now.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: These two bytes may not matter to you...
« Reply #95, on September 9th, 2011, 05:52 PM »
(Then it's settled.)

An amusing one... (Search2.php)

Code: [Select]
'age' => '((m.id_msg - t.id_first_msg) / CASE WHEN t.id_last_msg = t.id_first_msg THEN 1 ELSE t.id_last_msg - t.id_first_msg END)',

I know CASE is supposed to be pretty fast, but... Faster than MIN()?!

Code: [Select]
'age' => '((m.id_msg - t.id_first_msg) / MIN(1, t.id_last_msg - t.id_first_msg))',

Wouldn't that be simpler...?
The wonders of mysql....

(Yeah, I'm trying to make sense out of the search system and understand why the fuck it won't sort posts by date like I asked it to... >_<)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: These two bytes may not matter to you...
« Reply #96, on September 9th, 2011, 05:56 PM »
Quote
I know CASE is supposed to be pretty fast, but... Faster than MIN()?!
Testing for equality plus a CASE is probably faster than MIN when you have to apply to every single row in a virtual table, especially one that's on disk because it's a filesorted table. And, possibly, for PGSQL/SQLite compatibility, who knows.
Quote
(Yeah, I'm trying to make sense out of the search system and understand why the fuck it won't sort posts by date like I asked it to... >_<)
Did you change the weights?

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: These two bytes may not matter to you...
« Reply #97, on September 9th, 2011, 06:00 PM »
Quote from Arantor on September 9th, 2011, 05:56 PM
Testing for equality plus a CASE is probably faster than MIN when you have to apply to every single row in a virtual table, especially one that's on disk because it's a filesorted table. And, possibly, for PGSQL/SQLite compatibility, who knows.
Hang on... You're telling me that long CASE THEN ELSE END line is going to be *faster*? How come? :lol:
I'll trust you on that but... It means I have to rewrite all of my MIN() and MAX() calls then :P
Quote
Quote
(Yeah, I'm trying to make sense out of the search system and understand why the fuck it won't sort posts by date like I asked it to... >_<)
Did you change the weights?
That's the thing... As a lambda user, I don't want to have to change obscure search settings! I want it to work like any normal guy would do the sorting: take the most recent post in the list, then the second most recent... Etc.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: These two bytes may not matter to you...
« Reply #98, on September 9th, 2011, 06:05 PM »
I don't know if that's the case for sure, but that's the only explanation I can come up with. Benchmark it :P

Remember, certain operations apply in certain ways under certain circumstances. This is about the worse possible circumstance to deal with where the odds are stacked against you: you're doing everything on disk, drawing more file I/O that's blocking other requests and so on.

I can only surmise that it's a performance thing, because if it wasn't, MIN would be much more logical.
Quote
That's the thing...
I'm not trying to worry about it as a regular user. You want to know why it's misbehaving. If you tweak those settings, does it behave as expected?

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: These two bytes may not matter to you...
« Reply #99, on September 9th, 2011, 08:53 PM »
- I don't know and I don't want to know, come to think of it... :lol: Good thing you're our DB specialist here :P

- That's the thing: I shouldn't have to tweak any settings... The search engine offers me to sort by 'most recent topics'. It should return the latest messages in order. Perhaps it actually returns the latest topics in order -- i.e. by topic ID instead of msg_id, I haven't checked, but it doesn't work, that's my point... Weights are totally irrelevant here.

- Okay, SMF bugs... While working on fixing a bug of mine (wrong link for new posts), I noticed a few inconsistencies in SMF:
--- in MessageIndex, the new_href link ends with ";topicseen". In Recent.php, these links don't. This needs to be harmonized...
--- the 'href' link is wrong. It ends with a test which, in one case, adds "new" to the URL... It should be "#new", I reckon. I guess that link was never used anywhere.

Any opinions? I have to go eat...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: These two bytes may not matter to you...
« Reply #100, on September 9th, 2011, 10:19 PM »
topicseen is mostly a legacy item IIRC, if it doesn't affec behaviour, ditch it.

As for new, that one's required. #new anchors the page in the browser, but it won't get you to the right page of a multipage thread, while topic=x.new will get you to the right page.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: These two bytes may not matter to you...
« Reply #102, on September 9th, 2011, 10:33 PM »
About new, what I mean is that their code basically ends the page with ";topicseennew" instead of ";topicseen#new". The start page is already accounted for at this point.
Since I've never seen a topicseennew link, means the string is built and never used...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: These two bytes may not matter to you...
« Reply #104, on September 15th, 2011, 01:39 AM »
You don't know? That's a first 8-)
Well, from what I gathered, it updates your session with a list of unread topics. If all topics in a board are read, it marks the board as read (i.e. saves space in the logs.)

I suppose it doesn't do it automatically because it can be expensive in CPU cycles or something like that...

Ah, long time since I found an option we could remove from Wedge: compactTopicPagesEnable. I don't really see the point in having fully expanded page links...?
Posted: September 9th, 2011, 10:46 PM

Bump for message above.

Also: pm_email_notify -- it's set to 0 by default. It seems that this means "never send an e-mail notification". I thought that SMF's default was to send them...? It makes more sense to have this on by default...
« Login/Register Feature
Need some help on a UI matter »