Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Arantor
3721
The Pub / Re: Starting date of the topic in the subject index
« on April 18th, 2012, 07:33 PM »
I guess, but I think I'd rather avoid it entirely, I just think it's too much stuff in the message index, even if it's not immediately visible.
3722
Archived fixes / Re: Buggy Feed links
« on April 18th, 2012, 07:32 PM »
Quote
We should always sanitize $_GET anyway. Just assume that ; is always used to separate stuff. Which is the case, anyway...
Occasionally though, SMF uses '&', as in the SID injector, and I don't know what it's there for. I'm assuming this is to 'emulate' enable_trans_sid being set to 1. Because I guess some servers won't allow you to use ini_set, if it's at 1, then it automatically injects & at the end of the SID and then you end up with two different URL styles to deal with -- ?PHPSESSID=...; and ?PHPSESSID=...& -- so they chose to inject & and deal with it later (which I don't believe they do...)
I for one couldn't care less about that, but I suppose we should deal with it overall?
We always do sanitise $_GET, and we do always assume that ; is used to separate stuff, as noted.

Yes, & is passed into SID, and I think you're probably right that it is related to handling enable_trans_sid.

Dealing with it is the big problem. How, exactly, do we proceed? I'm in no doubt the current situation is not ideal. But I'm not sure the other situations are any better either.
Quote
I hope you liked the name I chose for the setting :lol:
Although I'm never one to refuse SID! But only if it's C64-related
I haven't actually looked, been too busy to properly keep up with all the code changes :/
Quote
The same could be said of a session ID. If I have my forum running on 3 different browsers, should Wedge say I have 3 users online...? For debugging purpose it's fine. What about Googlebot? Sometimes you get many requests from the same IP IIRC. Because they're all using different sessions, Wedge considers them as multiple bots. I for one would rather see it recognized as a single 'user'.
If you have your forum running on three different browsers, it depends whether you're logged in or not. If you're logged in, you should be able to have three sessions but only the one online user. But if they're not all logged in, it is different users per se, and I'd argue that's more accurate because they're three separate experiences of browsing the site.

If you have two different sessions from Google, that's two different bots browsing, and should be reflected as such, despite maybe coming from separate - or the same - IP addresses. Here's the thing, even now you cannot rely on an IP address being reflective of a single bot.

Two bots from Google browsing, with two sessions, will typically have two IP addresses. Though it won't always be that way.
Quote
It should always be there in homepage links (index.php). And never elsewhere.
I was going off the feed validation I ran, I forget exactly what was, and what wasn't, broken
3723
Archived fixes / Re: SMF bug 4956 (slash in cache key causes cache to fail)
« on April 18th, 2012, 07:23 PM »
Quote
We could also 'simply' create subfolders in /cache/ named after the cache hash... And store files in them (without the starting hash, of course.)
At least it wouldn't break/kill the cache (at least too soon) if files can't be removed.
There are problems with doing that, namely that for every folder, you'd have to make sure that index.php/.htaccess were also added to each folder. Honestly it would be better not to do that and flatten its structure.
Quote
I guess we could also use urlencode() or something...
Is % a valid filename character? ;)
Quote
That's a pointless micro-optimization, in the end. It's obvious that PHP caches that value.
I saved the hash into $settings['cache_hash'] (I know it's not a good idea to use that global, but I don't want to pull $context into itself within the cache functions... Bad karma?), and did some benchmarking. (1000 calls to retrieve 'settings', which is the bigger cache file...)
Interesting. I guess it's hard to really optimise something like that properly.
3724
Archived fixes / Re: SMorg
« on April 18th, 2012, 07:11 PM »
Quote
The url bug... Well, it's probably a case of "I don't want to fix it before I understand why it works in SMF and not in Wedge..."
It works in SMF because SMF doesn't have the extra changes that we've made plus what was in Aeva. Comment out the call from aeva_on_posting() to aeva_autolink_urls() and it should work fine.
3725
Plugins / Re: Light URL Plugin Maybe?
« on April 18th, 2012, 07:10 PM »
Quote
Except that they don't have to use that scheme at all...
This is the problem: users are going to expect them to do so. Just as users even now bitch about the fact that Aeva doesn't properly support pretty URLs. The more complex the ways you make it accessible, the harder it is for plugins to do it.

Why, exactly, do we need another route to access content, when we already have index.php?action=something;param1=val1;param2=val2 and /do/something/whatever/whatever ?
3726
Archived fixes / Re: Time offset (auto detect)
« on April 18th, 2012, 07:08 PM »
Quote
I was looking at php.net and everything, and was at a loss. What should I do?
This is why it's a complete fuck up, start to finish.
Quote
I'd really rather rely on Wedge asking me to say where my timezone is (Europe > Paris), rather than having to select a timezone based on whatever cities we decided to include in the list...
Do you *really* want to put a 470-odd long select list into the *general user area*? It's bad enough having it in the admin area.

Consider also that other forums perform just fine having multiple cities grouped together without any problems.
Quote
Heck, we could even simply ask them for their country (okay let me just type 'F' here in the dropdown list... That's it, France...), and then automatically load a list of available timezones for the country
If you want to do it, go nuts. Ever delving into timezones is one of the (very few) things I've ever regretted taking on with Wedge. The entire situation is a fucking mess, long before we came along, Just remember that whatever you do, you're cleaning up an operation that users will only see on registration and when they delve into their profile, they won't see it the rest of the time.

Have fun with managing that 470-odd list down into the groups you're hoping for, it took me long enough to compile the list I had.

(Sorry for my attitude, I'm tired, achy, pissed off with the weather here and I have other stuff going on out here in RL that's bugging me, like the fact that I'm in the process of taking my name off the house that I bought almost 5 years ago as the place I wanted to spend the rest of my life :()
3727
Plugins / Re: Plugins I refuse to do
« on April 18th, 2012, 07:02 PM »
Quote
I don't read AAF, but I have a tab opened on your list of recent posts, so I can try and follow what you're replying to
I reply to most topics. Aside from dispelling a lot of the smug 'XenForo is better' crap, it does give me a decent barometer as to what people are using software for.
Quote
Didn't know it even had a name, eheh...
They'd have to know we have a math question at that point though...
MATHCHA is even more bastardised a name than CAPTCHA is, heh, but yes, that's what it's known as. Figuring out that it's a math question is not that hard, however.
Quote
The whole point of having it core, is precisely that you can then make sure that you're protected from 99% of spam right at install time.
Except that you're not, not nearly 99%. However, I do agree that it might be useful to generate a question like that as an example, I just wouldn't implement it like that (I'd generate it in the install language and install it directly as a question), so that instead of having {equation} show up in the Q&A area, it would show up with the actual question.
3728
Archived fixes / Re: Topic Cache Triggers IDM
« on April 18th, 2012, 06:59 PM »
It's your browser. A normal browser would accept the compressed JavaScript and not try to push it to a download manager.
3729
Features / Re: gallery from the admin pov
« on April 18th, 2012, 06:58 PM »
Quote
- Creating an folder/subfolder... is much too complicated.
Except that it's far more involved than just creating a new folder. Albums have permissions, just because you want to share your pictures with everyone does not mean the rest of us do. In fact, there are multiple albums here that are deliberately not shown to everyone - which *requires* having that extra UI.
Quote
The Aeva way of creating folders made it impossible to use for nearly every normal user.
Or not, seeing how most users I've spoken to actually seem to manage it.
Quote
It is nice and for technical affine people no problem. But if you look from the mother/girlfriend/normal facebook user views this step is nearly impossible.
Quote
Better would be that you have an button at "insert a picture from gallery" at creating a post.
That's been there for years in the 2.x (paid) line and is in Wedge.
Quote
To design a board software from the "normal user" view is difficult i know, but i hope you can achieve an easy to use software for everyone :)
You're not asking us to design it for 'normal users', you're asking us to design it for idiots, who are less competent than you give them credit for. We've spoken to users, we use this stuff on our own sites, day in and day out, and believe me, you're the first person to ask for it to be simpler.
3730
Archived fixes / Re: SMorg
« on April 18th, 2012, 04:36 PM »
The bbc url tags keep appearing as a result of a known bug in Wedge that we have narrowed down from thousands upon thousands of lines of code to a few dozen - but not yet figured out exactly *where*.

As for this one, the profile fields do need going back over, and as discussed, size should be used anyway (which will do more than just fix the maxlength of the HTML textbox)
3731
Plugins / Re: Light URL Plugin Maybe?
« on April 17th, 2012, 08:41 PM »
For putting this in core, I'm not sure why this is useful as compared to having Pretty URLs in core, but maybe that's just me
Quote
I don't see where there's a problem with it...?
If you're creating short hashes that include t or b as references to topics and boards, that's fine - but how does that work for plugins? What hoops do plugins have to go through in order to work? Plugins will naturally just fall in with pretty URLs (e.g. domain.com/do/pluginaction) without any work, and if they want to use pretty URLs, they can declare extra filters, but even that is going to be more effort than it's usually worth, so they won't bother. If you not expect them to have to work with yet another URL routing scheme (optionally or otherwise), it's just more hassle for plugin authors, especially when people will ask them how to make it work.

More than one person asked how to make Aeva Media work with pretty URLs, and the same's going to be more and more true when it's more thoroughly implemented (since it's all in the core now)
3732
Archived fixes / Re: SMF bug 4956 (slash in cache key causes cache to fail)
« on April 17th, 2012, 08:35 PM »
Quote
My, you always have an answer to everything...
Well, I've had to work with it in the past, hence I did know about it. Plus there are plenty of places where it actually checks settings_updated to avoid calling on cache (usually where on level 2+ where the cache key is the only thing, there won't be a way of invalidating it so easily)
Quote
So, in order to retrieve the cache hash, I would need to first get the cache hash and then retrieve the cache based on that cache hash... THEN I can know what the cache hash is :^^;:
It is sort of complicated, yes :P
Quote
Hmm, I was thinking... md5() is a 128-bit number, so it's something like at least a billion billion billion billion... Thinking about it, since we can barely have more than 2000 files in a folder, it's very, very unlikely to get a collision -- ever... No?
It's not quite like that, no. The problem with cache keys is that they're all in the one folder - everything goes into $cachedir, and everything would notionally get the same md5() process applied, so you're not just considering collisions across the namespace of a single album's files, but collisions across everything that the md5() is applied to, which is potentially every media item (since we only need apply the md5 if there isn't a / in the supplied cache key)

That said, md5 might be 128 bits, but it's not 128-bit wide in collision cases. It was proved a few years ago that for collision purposes, the keyspace isn't 2^128 but more like 2^40 due to weaknesses in the way it's generated.
Quote
I forgot about the slash being a valid base64 char. Oh, my... They should have chosen something else! It's not like there are so few valid characters for an URI...
Actually, there aren't that many characters truly valid in a URI, the vast majority of them have... extra meanings, and are normally just %-encoded instead.
Quote
Hmm, I like that... bin2hex seems to be fast indeed.
I was also looking into sha1(), crypt('sha256') and pack() (there are plenty of options to convert these), or even using base_convert() to automatically use alphanumeric characters only...
But bin2hex could be just as simple :P
Although not as secure as a md5() on boardurl.filemtime...
Certainly it's fast, and for short keys it's faster than even base64. I'd avoid crypt, though, there were issues with it and related functions in 5.3.7, pack() is really just a super-sized version of what bin2hex is doing anyway, heh.

You're right, it's not as secure as md5ing the filemtime, and that's reasonably important for the sake of safety.
Quote
Oh, Pete -- how about we calculate that md5 hash only ONCE per page...? It seems stupid not to do it. We could simply store it in $context['cache_hash'] or something... If empty, just fill it in...
Works for me. :)
3733
Bug reports / Re: Pretty URL remarks
« on April 17th, 2012, 05:13 PM »
The other benefit of using SMF's caching is that if you're using something like memcached or APC, it transparently caches *there* rather than in the DB without any code change on your behalf.

That reminds me I need to do other caching changes, actually.
3734
Plugins / Re: Light URL Plugin Maybe?
« on April 17th, 2012, 02:30 PM »
And that goes back to what was said earlier about having a reliance on a third party. And even then there are still problems with doing it.
3735
Archived fixes / Re: SMF bug 4956 (slash in cache key causes cache to fail)
« on April 17th, 2012, 02:26 PM »
To be honest, bin2hex is only a percentage longer than base64 anyway, but it's certainly the fastest of the practical options. Filename length is only an issue with long keys - which is mostly related to media where this all started :/