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.
Topics - Arantor
196
Off-topic / How to piss Arantor off, part 2: take the view that he's a negative person
« on March 13th, 2012, 12:27 PM »
For those of you wondering, I'm not really a negative person. I'm cynical, sure, but only because I've had to deal with so many idiots that I have little faith left in humanity.
And then we get gems like this: http://anotheradminforum.com/forum-management/custom-footer-info/
And then we get gems like this: http://anotheradminforum.com/forum-management/custom-footer-info/
197
Features / So, looking at the user banning subsystem
« on March 13th, 2012, 02:40 AM »
I know I blogged about it a long time ago about the things to do with banning, and to be fair a lot of that still applies (the whole deal with whitelisting and blacklisting email addresses/domains and the things concerning blocking IP address ranges)
But it's the per user stuff that intrigues me. I speculated before about a setup whereby you could remove permissions from users based on permissions, and I suggested at the time that you could do it based on warnings, so that 10% was watched but that as you increased the warnings, you could gradually remove more permissions like avatars and so on, before getting as far as post banning.
I struggled to figure out how the interface for that might look, and of course I'm always thinking of interesting new variations that can be carried out on this, as well as integrating Annoy User.[1]
So here's what I'm thinking, allowing for the defaults and so on. The first block would be a set of sliders ranging from 0 to 100 (like the issue warning screen uses) and would be the 'warning level at which...'
* users are watched
* users' avatars are hidden
* users are post moderated
* users are prevented from posting
* users are prevented from accessing the site at all
* max % warning a single moderator can apply per day
* groups allowed to issue a warning that would ban a user from accessing the site at all
* groups allowed to issue per-user punishments
That's it for general configuration. For the user-specific stuff when you're issuing the warning...
* the warning level
* whether the warning level will drop and if so by how much per day/when it will expire (only if the user can issue per-user punishments)
* per user punishments (including when they will expire)
- no avatar
- no signature
- random user annoyances[2]
- disemvowelling[3]
- moderation
- no forum access
- other to be added through hooks
This seems a bit vague to me but I can't think of anything it's missing >_>
But it's the per user stuff that intrigues me. I speculated before about a setup whereby you could remove permissions from users based on permissions, and I suggested at the time that you could do it based on warnings, so that 10% was watched but that as you increased the warnings, you could gradually remove more permissions like avatars and so on, before getting as far as post banning.
I struggled to figure out how the interface for that might look, and of course I'm always thinking of interesting new variations that can be carried out on this, as well as integrating Annoy User.[1]
So here's what I'm thinking, allowing for the defaults and so on. The first block would be a set of sliders ranging from 0 to 100 (like the issue warning screen uses) and would be the 'warning level at which...'
* users are watched
* users' avatars are hidden
* users are post moderated
* users are prevented from posting
* users are prevented from accessing the site at all
* max % warning a single moderator can apply per day
* groups allowed to issue a warning that would ban a user from accessing the site at all
* groups allowed to issue per-user punishments
That's it for general configuration. For the user-specific stuff when you're issuing the warning...
* the warning level
* whether the warning level will drop and if so by how much per day/when it will expire (only if the user can issue per-user punishments)
* per user punishments (including when they will expire)
- no avatar
- no signature
- random user annoyances[2]
- disemvowelling[3]
- moderation
- no forum access
- other to be added through hooks
This seems a bit vague to me but I can't think of anything it's missing >_>
| 1. | And no, I'm still not going to add IP ranges to that. I never did it when I first made Annoy User, damn sure I'm not going to add it now. |
| 2. | Essentially those from the Annoy User mod. |
| 3. | A subtle but effective technique: go through the user's posts and remove any extraneous vowels. Leave entities and tags intact of course, but vowels in the main content get removed. Good way of annoying users, just need to remember to do it after bbc parsing and just do it on the non HTMLified contents. I already have some code for doing this. |
198
Archived fixes / Linktree
« on March 12th, 2012, 05:24 PM »
We gotta fix this, it's missing a few things that I think need fixing; it's most prominent to me because of the theme work I've been doing.
* when in the board index, there's nothing in the linktree, and it should really have something
(site name > Community?)
* when in a given category specifically
(site name > Community > Category?)
Thoughts?
* when in the board index, there's nothing in the linktree, and it should really have something
(site name > Community?)
* when in a given category specifically
(site name > Community > Category?)
Thoughts?
199
Off-topic / Another WIP
« on March 12th, 2012, 03:13 AM »
I've been very restless today with everything going on, so much so that I couldn't concentrate on doing proper work for a friend like I was meant to (sorry, you know who you are, and I didn't trust myself to touch your stuff when I'm in this mood, but I'll deal with that in the morning)
So I figured I'd pass the evening on something that might cheer me up a little and that I could happily vent some spleen by swearing at it when it didn't work properly.
Some of you may remember that I had a subscription for BlocWeb and that I was a big fan of some of his themes - one that I always liked was BlueLight. It's a pretty minimal theme, lots of nice gradients, and I figured I might give something like it a shot for Wedge.
And here's the result. It's still heavily WIP, based on Wine, but tweaking the menu is what's taken me over an hour to get to this point (and even then it's still not done)... but it is done entirely in CSS :D
Works great on current Chrome beta and Firefox stable, IE9 is a mixed bag a bit, but it's WIP and I don't care about IE much. It's more about seeing what I can do with CSS because it's not my favourite tool and I don't see myself as a designer much.
So I figured I'd pass the evening on something that might cheer me up a little and that I could happily vent some spleen by swearing at it when it didn't work properly.
Some of you may remember that I had a subscription for BlocWeb and that I was a big fan of some of his themes - one that I always liked was BlueLight. It's a pretty minimal theme, lots of nice gradients, and I figured I might give something like it a shot for Wedge.
And here's the result. It's still heavily WIP, based on Wine, but tweaking the menu is what's taken me over an hour to get to this point (and even then it's still not done)... but it is done entirely in CSS :D
Works great on current Chrome beta and Firefox stable, IE9 is a mixed bag a bit, but it's WIP and I don't care about IE much. It's more about seeing what I can do with CSS because it's not my favourite tool and I don't see myself as a designer much.
200
Off-topic / IT'S OVER 9000!
« on March 10th, 2012, 01:51 PM »
MY POST COUNT :D
That is all. Have a good day.
That is all. Have a good day.
201
Features / Image resizing for non-uploads
« on March 8th, 2012, 03:56 PM »
Right now we have the ability to limit the image size of images posted via the img tag, to ensure they're not made huge.
E.g. if you try and post a massive photo but the settings say 150x150, you get a 150x150 size shown (though it doesn't actually resize/thumbnail the image, it just shows it at that size)
What I'm wondering is whether it might not be a bad idea to indicate that the picture isn't full size in those cases and have it automatically link back to the full size image - or even make use of Zoomedia to do that?
E.g. if you try and post a massive photo but the settings say 150x150, you get a 150x150 size shown (though it doesn't actually resize/thumbnail the image, it just shows it at that size)
What I'm wondering is whether it might not be a bad idea to indicate that the picture isn't full size in those cases and have it automatically link back to the full size image - or even make use of Zoomedia to do that?
202
Plugins / Mad idea but it might just work
« on March 7th, 2012, 05:54 PM »
OK, so I've been trying to figure out how to cope with this. One of the biggest problems with SMF's environment is that it makes your files writable by everything, essentially. You have to make your site vulnerable on shared hosting in order to upload and install mods - even pure hooks ones.
In our case, there's no file edits at all. But there's still the upload problem: you have to write something to the relevant folder. Which means that folder has to be writable by the webserver.
So, I tried a different tact, what if through some process, we no longer required write access to that folder, but that we could delegate it off to something which did? Or, as I call it, you upload the plugin file, it goes into the system temp folder (where all uploaded files go), where it's unpacked.
Here's the trick: instead of uploading it into a physical folder or something like SMF does, we unpack it serially (going through the archive file by file), push the file to temp, then we send it via FTP from our script to the server. It's seemingly stupid but I see no reason why it won't work, other than the mechanics are a PITA.
Doing that means you don't have to make the folder writable or indeed do anything to it, essentially it's being uploaded to by you (and thus OWNED by you) just as if you uploaded it yourself. No changing permissions, no changing them back.
The caveat is that I would remove direct local filesystem support. This would make for a slight inconvenience on test forums/localhost where FTP isn't configured, because it would mean there would be no facility for uploading as SMF currently does. But the price paid in convenience is security: if you don't ever have direct filesystem support, there's no need to screw around with making things 777 (and hopefully that plague of bad advice will not follow us here), and it's not like you can't just unpack it and upload it yourself.
I have the uncomfortable feeling it would pretty much demand .zip support because the contents of /tmp are intentionally unstable and I'm not sure how comfortable I am with unpacking a .tar.gz in /tmp and expecting it all to be there after (as opposed to .zip which can be handled a file at a time)
So, thoughts? Concerns? Questions? Anything that didn't make sense and people would prefer I explained it in actual English?
In our case, there's no file edits at all. But there's still the upload problem: you have to write something to the relevant folder. Which means that folder has to be writable by the webserver.
So, I tried a different tact, what if through some process, we no longer required write access to that folder, but that we could delegate it off to something which did? Or, as I call it, you upload the plugin file, it goes into the system temp folder (where all uploaded files go), where it's unpacked.
Here's the trick: instead of uploading it into a physical folder or something like SMF does, we unpack it serially (going through the archive file by file), push the file to temp, then we send it via FTP from our script to the server. It's seemingly stupid but I see no reason why it won't work, other than the mechanics are a PITA.
Doing that means you don't have to make the folder writable or indeed do anything to it, essentially it's being uploaded to by you (and thus OWNED by you) just as if you uploaded it yourself. No changing permissions, no changing them back.
The caveat is that I would remove direct local filesystem support. This would make for a slight inconvenience on test forums/localhost where FTP isn't configured, because it would mean there would be no facility for uploading as SMF currently does. But the price paid in convenience is security: if you don't ever have direct filesystem support, there's no need to screw around with making things 777 (and hopefully that plague of bad advice will not follow us here), and it's not like you can't just unpack it and upload it yourself.
I have the uncomfortable feeling it would pretty much demand .zip support because the contents of /tmp are intentionally unstable and I'm not sure how comfortable I am with unpacking a .tar.gz in /tmp and expecting it all to be there after (as opposed to .zip which can be handled a file at a time)
So, thoughts? Concerns? Questions? Anything that didn't make sense and people would prefer I explained it in actual English?
203
Features / Unfinished, quite raw, would like some feedback
« on March 5th, 2012, 02:46 PM »
For a while we've talked about the illogical nature of the theme settings that are really member preferences and how they are theme specific.[1]
A while ago I brought a new area into the admin panel, called Member Options. It held some of the generic options for members, custom profile fields and signatures, and now I've tried to put the preferences configuration there, in hopefully a less brain-dead fashion.
Except I'm not sure I like the UI very much and I'm not sure how best to fix that.
The 'Change' button is hidden by default, visible when you mouse over the relevant area (like the thoughts button does) and when you select it, it goes from the 'default value: blah' into two dropdowns, one to select what happens with guests/new members, and one for existing members. As you can see this isn't finished yet. (I made one visible to show you what it would look like)
The thing is, while I think it's about the only sane way to complete this UI, I don't like it. It's boring, bland, unimaginative and I just don't like it but I can't figure out how to improve it without making it less usable. (Though I'm debating pulling out the magical hide factor and just having the modify buttons there the whole time, it'll be more obvious what to do then at least)
Thoughts?
A while ago I brought a new area into the admin panel, called Member Options. It held some of the generic options for members, custom profile fields and signatures, and now I've tried to put the preferences configuration there, in hopefully a less brain-dead fashion.
Except I'm not sure I like the UI very much and I'm not sure how best to fix that.
The 'Change' button is hidden by default, visible when you mouse over the relevant area (like the thoughts button does) and when you select it, it goes from the 'default value: blah' into two dropdowns, one to select what happens with guests/new members, and one for existing members. As you can see this isn't finished yet. (I made one visible to show you what it would look like)
The thing is, while I think it's about the only sane way to complete this UI, I don't like it. It's boring, bland, unimaginative and I just don't like it but I can't figure out how to improve it without making it less usable. (Though I'm debating pulling out the magical hide factor and just having the modify buttons there the whole time, it'll be more obvious what to do then at least)
Thoughts?
| 1. | Actually, the code does indicate some of them should update only the default theme (i.e. regardless of what theme you're actually configuring) but I'm not entirely sure it works properly. Even if it does, it's highly illogical. |
204
Off-topic / Interesting reading
« on March 5th, 2012, 11:27 AM »
This guy has a lot to say about security, http://www.cs.auckland.ac.nz/~pgut001/
The most interesting one from my point of view so far has been this PDF: http://www.cs.auckland.ac.nz/~pgut001/pubs/stupid.pdf
What's more interesting is that there's very little there to surprise me, but it's confirmed a lot of what I've long suspected or known about user behaviour, and how broken the digital world really is.
And if you want a lesson in how to make a point thoroughly, http://www.cs.auckland.ac.nz/~pgut001/pubs/unsolvable.pdf is it. To wit: adding cryptography does not implicitly/inherently make something more secure. I love the way he makes that point.
And I LOVE how he explains why DRM is broken (unsolvable.pdf). I'm so glad that it isn't just me that bangs that drum because it bloody feels like it a lot.
There's many more articles on security there, some ranging from the more abstract like the ones I've linked, to rather more technical ones about cryptography and flaws in algorithms, which is interesting reading in itself if you're curious about that kind of thing.
The most interesting one from my point of view so far has been this PDF: http://www.cs.auckland.ac.nz/~pgut001/pubs/stupid.pdf
What's more interesting is that there's very little there to surprise me, but it's confirmed a lot of what I've long suspected or known about user behaviour, and how broken the digital world really is.
And if you want a lesson in how to make a point thoroughly, http://www.cs.auckland.ac.nz/~pgut001/pubs/unsolvable.pdf is it. To wit: adding cryptography does not implicitly/inherently make something more secure. I love the way he makes that point.
And I LOVE how he explains why DRM is broken (unsolvable.pdf). I'm so glad that it isn't just me that bangs that drum because it bloody feels like it a lot.
There's many more articles on security there, some ranging from the more abstract like the ones I've linked, to rather more technical ones about cryptography and flaws in algorithms, which is interesting reading in itself if you're curious about that kind of thing.
205
Sorry for yet another topic about a single admin setting, but I think it needs a bit of discussion.
Admin > Configuration > General > Poll Mode
You can set it to enable polls (default), disable polls, or show polls as topics. This is a bit weird, so let me explain.
If you disable polls (as opposed to show polls as topics), the poll+topic is actually hidden, it's hidden in message index, it's hidden in unread/unreadreplies, though you can still access the topic directly (which seems to me to defeat the point a bit). If you just 'show polls as topics', it's as though the poll was never added and there are no permissions to add/vote etc.
I don't know about you, but I never came across anyone who ever did properly disable polls, it's always done with permissions rather than outright turning them off (which says to me that people don't realise the option's there) and even if they did know it was there, I can't really see people using it.
So, I'm proposing to remove it, but I want to be sure that no-one's going to use it if I do. It isn't something that can be easily added back with a plugin.
Admin > Configuration > General > Poll Mode
You can set it to enable polls (default), disable polls, or show polls as topics. This is a bit weird, so let me explain.
If you disable polls (as opposed to show polls as topics), the poll+topic is actually hidden, it's hidden in message index, it's hidden in unread/unreadreplies, though you can still access the topic directly (which seems to me to defeat the point a bit). If you just 'show polls as topics', it's as though the poll was never added and there are no permissions to add/vote etc.
I don't know about you, but I never came across anyone who ever did properly disable polls, it's always done with permissions rather than outright turning them off (which says to me that people don't realise the option's there) and even if they did know it was there, I can't really see people using it.
So, I'm proposing to remove it, but I want to be sure that no-one's going to use it if I do. It isn't something that can be easily added back with a plugin.
206
Features / Home button
« on March 4th, 2012, 07:04 PM »
While I'd love Wedge to be the base of sites, I know that a significant number of users will be using it as an extra feature on a site they already run, as evidenced by the number of people who want to change where the home tab on the main menu goes.
What I would suggest then is to provide a space to enter a URL into. If the box is empty, all is as it is now, but if the box is filled with a URL, we should put that into the title heading (instead of scripturl) and we should tweak the menu, home would point just to this URL, and what was the home tab will become a "Community" tab with drop downs as we have now.
Thoughts?
(FWIW, XenForo does this.)
What I would suggest then is to provide a space to enter a URL into. If the box is empty, all is as it is now, but if the box is filled with a URL, we should put that into the title heading (instead of scripturl) and we should tweak the menu, home would point just to this URL, and what was the home tab will become a "Community" tab with drop downs as we have now.
Thoughts?
(FWIW, XenForo does this.)
207
Features / Pretty URLs things
« on March 4th, 2012, 06:41 PM »
Just playing around with it now.
* Board URLs
They're not set up in the DB properly for any boards other than the first one, so we will need to fix that at some point, on my test site, smf/wedge/general is the first board, as it should be, but a new board created before PURLs was enabled is simply internally as /new-board-1/ rather than having the prefix.
* Topic URLs
I was going to say this was broken but I rechecked the DB and hadn't updated the key on it. Mind you, if the topic ID is in the URL, why exactly do we need to cache/index the title separately?
* Board URLs
They're not set up in the DB properly for any boards other than the first one, so we will need to fix that at some point, on my test site, smf/wedge/general is the first board, as it should be, but a new board created before PURLs was enabled is simply internally as /new-board-1/ rather than having the prefix.
* Topic URLs
I was going to say this was broken but I rechecked the DB and hadn't updated the key on it. Mind you, if the topic ID is in the URL, why exactly do we need to cache/index the title separately?
208
Archived fixes / SMF bug 4962 (pressing cancel on the AJAX notification doesn't cancel it)
« on March 4th, 2012, 02:16 AM »
All the 'cancel' link on an AJAX notification does is hide the 'Loading...' notification.
While we could theoretically just change the text to say 'close', I'd rather we either removed it entirely or we actually made it cancel. That shouldn't be too problematic, since we should be able to call .abort() on the object being used to handle the XHR itself (AIUI, jQuery > 1.5 exposes all methods from the XHR)
All we'd actually need to do is have it so that when we show the notification, we pass something to it by which we can call the abort... assuming we do that. If we don't, it gets a bit trickier to handle. Mind you... if we have two concurrent AJAX requests for whatever reason and both trigger 'Loading', it's impossible to know which would actually be cancelled.
Hmmm. Maybe it should just be renamed (or simply remove the hide button since having it really doesn't achieve anything useful)
Bumpity. Inclined to simply remove the hide button, by the way, unless anyone has any burning issues with wanting to actually attempt to cancel the AJAX request?
While we could theoretically just change the text to say 'close', I'd rather we either removed it entirely or we actually made it cancel. That shouldn't be too problematic, since we should be able to call .abort() on the object being used to handle the XHR itself (AIUI, jQuery > 1.5 exposes all methods from the XHR)
All we'd actually need to do is have it so that when we show the notification, we pass something to it by which we can call the abort... assuming we do that. If we don't, it gets a bit trickier to handle. Mind you... if we have two concurrent AJAX requests for whatever reason and both trigger 'Loading', it's impossible to know which would actually be cancelled.
Hmmm. Maybe it should just be renamed (or simply remove the hide button since having it really doesn't achieve anything useful)
Posted: March 1st, 2012, 02:50 PM
Bumpity. Inclined to simply remove the hide button, by the way, unless anyone has any burning issues with wanting to actually attempt to cancel the AJAX request?
209
Bug reports / SMF bug 4953 (PS adds 'cellTextIsHtml' to JPGs causing them to fail checks)
« on March 2nd, 2012, 02:21 PM »
There are a surprising number of ways to get false positives in images, and I'm not sure how useful the current code is in stopping threats.
I remember discussing this issue with several people at SMF when this originally blew up way back.
The problem that isn't really being solved here is that you have legitimate images (and other files) being uploaded and checked for common things that could be malicious - but not nearly all of the things that could be, and unfortunately blocking others in the process like this one. The problem is that you can't realistically blacklist certain constructions and then provide exceptions, unless you're making very specific exceptions - and even then it's not reliable.
What might be better to do is to do separate types of validation based on the file type (assuming it's an image that you're trying to validate) and attempt to make sense of the file itself, e.g. if it's a GIF, step through and validate the image contents vs its headers and if there's any extra content, dump it. (Being sure to validate for animated images, of course)
It doesn't help that GIF, PNG and JPEG all legitimately allow for extra non-image information to be embedded in less than pleasant ways.
Posted: March 2nd, 2012, 10:55 AM
I remember discussing this issue with several people at SMF when this originally blew up way back.
The problem that isn't really being solved here is that you have legitimate images (and other files) being uploaded and checked for common things that could be malicious - but not nearly all of the things that could be, and unfortunately blocking others in the process like this one. The problem is that you can't realistically blacklist certain constructions and then provide exceptions, unless you're making very specific exceptions - and even then it's not reliable.
What might be better to do is to do separate types of validation based on the file type (assuming it's an image that you're trying to validate) and attempt to make sense of the file itself, e.g. if it's a GIF, step through and validate the image contents vs its headers and if there's any extra content, dump it. (Being sure to validate for animated images, of course)
It doesn't help that GIF, PNG and JPEG all legitimately allow for extra non-image information to be embedded in less than pleasant ways.
210
Bug reports / SMF bug 4860: $_SESSION['login_url'] misbehaves, especially from SSI
« on March 2nd, 2012, 12:51 PM »
I've noticed this on and off since 2.0 RC1.2 but never spent enough time to examine why it happened. Need to spend more time on this one, because there's no reason for it to misbehave.
And oddly enough I cannot cause it to misbehave. It works exactly as I would expect it to.
All I've done for testing is to create the following file:
Code: [Select]
And that worked exactly as expected, storing the login_url properly. Thing is, I can find no flaws in the chain of events that would ever cause it to be dropped. (Not even in SMF.)
Posted: March 2nd, 2012, 10:48 AM
And oddly enough I cannot cause it to misbehave. It works exactly as I would expect it to.
All I've done for testing is to create the following file:
<?php
require('SSI.php');
ssi_login('....?action=profile'); // obviously using the real URL
?>And that worked exactly as expected, storing the login_url properly. Thing is, I can find no flaws in the chain of events that would ever cause it to be dropped. (Not even in SMF.)