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
5746
Features / Re: New revs
« on October 23rd, 2011, 11:50 PM »
(1 modified, 1KB)
Revision: 1131
Author: arantor
Date: 22:46:12, 23 October 2011
Message:
! If using url_image_size, make sure that we send a valid Accept header. This won't make a huge difference in most cases but if the user is requesting an attachment that's going to be served through Wedge, the request will be killed otherwise. (Subs.php)
----
Modified : /trunk/Sources/Subs.php
Revision: 1131
Author: arantor
Date: 22:46:12, 23 October 2011
Message:
! If using url_image_size, make sure that we send a valid Accept header. This won't make a huge difference in most cases but if the user is requesting an attachment that's going to be served through Wedge, the request will be killed otherwise. (Subs.php)
----
Modified : /trunk/Sources/Subs.php
5747
Plugins / Re: Using permissions in plugins
« on October 23rd, 2011, 11:17 PM »
SD/WD didn't really have a lot of choice in terms of doing things, and now I look back, I'm amazed I was satisfied with 1.0 doing what it did, because it made a mess of the permissions page by adding a screen's worth of permissions, not to mention that it did confuse people by being somewhere other than where all the settings were. But by the time we got beyond 1.0's release, we pretty much *had* to roll out the newer permissions simply because they just didn't work in SMF's setup.
Right now though, I'm in the state of mind where I don't want to craft something that's acceptable, as it were, but to set forth the way it *should* be done. I'm not sure that just linking to a plugin's permissions is that useful from the plugin itself when for a similar amount of programming effort it can actually create that permission UI inline. (Adding permissions in a plugin, assuming it's using the standard template is a one line affair)
On the flip side, I can see the value of providing it in both places when you create a new membergroup/role/whatever. There it actually makes some kind of sense - but not a lot, when it still would likely be better putting it per-plugin, in the long run.
From where I'm standing, having a plugin integrate into the central permissions is actually more illogical, overall, than it being in the plugin area, especially since people are more likely to add new plugins than they are - generally - to add new member groups, and if they do add new member groups/roles/whatever, the odds are they're doing it for specific permissions anyway, so it's even more important to get it right.
As far as SD/WD's model goes, I'd pretty much provide the framework to larger plugins to be able to do that with the minimum of hassle. I still find it ridiculous that all the large mods all had to roll their own permissions framework because the core couldn't accommodate it, when there's no reason why a single framework couldn't cope with everything SD, Aeva and PT (just to name three) generally needed as far as permissions were concerned.
Right now though, I'm in the state of mind where I don't want to craft something that's acceptable, as it were, but to set forth the way it *should* be done. I'm not sure that just linking to a plugin's permissions is that useful from the plugin itself when for a similar amount of programming effort it can actually create that permission UI inline. (Adding permissions in a plugin, assuming it's using the standard template is a one line affair)
On the flip side, I can see the value of providing it in both places when you create a new membergroup/role/whatever. There it actually makes some kind of sense - but not a lot, when it still would likely be better putting it per-plugin, in the long run.
From where I'm standing, having a plugin integrate into the central permissions is actually more illogical, overall, than it being in the plugin area, especially since people are more likely to add new plugins than they are - generally - to add new member groups, and if they do add new member groups/roles/whatever, the odds are they're doing it for specific permissions anyway, so it's even more important to get it right.
As far as SD/WD's model goes, I'd pretty much provide the framework to larger plugins to be able to do that with the minimum of hassle. I still find it ridiculous that all the large mods all had to roll their own permissions framework because the core couldn't accommodate it, when there's no reason why a single framework couldn't cope with everything SD, Aeva and PT (just to name three) generally needed as far as permissions were concerned.
5748
Plugins / Using permissions in plugins
« on October 23rd, 2011, 10:24 PM »
This is sort of plugin related and it more directly affects plugins than it does anything else, I guess.
I think one of the current paradigms in SMF is wrong, that permissions should intrinsically be added to the permissions page - when it just doesn't make sense to do that sometimes.
I lost count a long time ago of the number of threads of people asking about things like nneonneo's shoutbox and asking how to set it so people see the shoutbox. Of course, the answer is to set permissions - but when permissions are set somewhere else from any configuration/settings that the shoutbox might have, it's illogical.
Ironically, SMF also features one method to actually deal with this, though most people don't realise it.
When I split the calendar out, as I will be doing shortly, I don't have to rework the permissions too much - because the UI of the calendar settings actually has an inline permissions facility, where you can set access by group (which feeds into the permissions system natively) to different calendar features, just as you can with general permissions.
Weirdly, though, it never really hit home to me until tonight just how broken the paradigm is. I dug out an old SMF 1.1.x test site, and decided to play around with the chess mod. It's pretty neat actually. But you have the Admin > Chess Admin area with Settings and Maintenance pages - then you have to go elsewhere for the permissions, and it jolted me when I had to get out there and reset it myself.
Had the permissions been inlined into the config pages, I wouldn't have had to look and no doubt had I been a newbie, I'd have been way more confused.
It makes me wonder though. When I get round to ripping permissions out and replacing them, do I actively need to consider putting roles in, with directly extensible support (like we have now), or is it actually better to bar plugins from touching the core permissions and making them put permissions in their own settings pages? (Obviously, provide facilities for doing this, SMF 2.0 and Wedge do actually do some of this, though it needs expanding to cope with _own/_any and non-general/context-specific permissions, as right now only general permissions can be dropped in easily)
I'm just thinking that simple plugins only need a permission or two and can trivially pull that in, complex plugins need something bigger but might as well get a dedicated section for it in their own admin area, without having to clutter up the core permissions - and it means that we don't have to worry about making it extensible on a UI level, and more importantly, plugins get to keep their facilities all under the one roof.
At least, that's how it is in my head. Would love to know what others think.
I think one of the current paradigms in SMF is wrong, that permissions should intrinsically be added to the permissions page - when it just doesn't make sense to do that sometimes.
I lost count a long time ago of the number of threads of people asking about things like nneonneo's shoutbox and asking how to set it so people see the shoutbox. Of course, the answer is to set permissions - but when permissions are set somewhere else from any configuration/settings that the shoutbox might have, it's illogical.
Ironically, SMF also features one method to actually deal with this, though most people don't realise it.
When I split the calendar out, as I will be doing shortly, I don't have to rework the permissions too much - because the UI of the calendar settings actually has an inline permissions facility, where you can set access by group (which feeds into the permissions system natively) to different calendar features, just as you can with general permissions.
Weirdly, though, it never really hit home to me until tonight just how broken the paradigm is. I dug out an old SMF 1.1.x test site, and decided to play around with the chess mod. It's pretty neat actually. But you have the Admin > Chess Admin area with Settings and Maintenance pages - then you have to go elsewhere for the permissions, and it jolted me when I had to get out there and reset it myself.
Had the permissions been inlined into the config pages, I wouldn't have had to look and no doubt had I been a newbie, I'd have been way more confused.
It makes me wonder though. When I get round to ripping permissions out and replacing them, do I actively need to consider putting roles in, with directly extensible support (like we have now), or is it actually better to bar plugins from touching the core permissions and making them put permissions in their own settings pages? (Obviously, provide facilities for doing this, SMF 2.0 and Wedge do actually do some of this, though it needs expanding to cope with _own/_any and non-general/context-specific permissions, as right now only general permissions can be dropped in easily)
I'm just thinking that simple plugins only need a permission or two and can trivially pull that in, complex plugins need something bigger but might as well get a dedicated section for it in their own admin area, without having to clutter up the core permissions - and it means that we don't have to worry about making it extensible on a UI level, and more importantly, plugins get to keep their facilities all under the one roof.
At least, that's how it is in my head. Would love to know what others think.
5749
Off-topic / Re: Doctor Who
« on October 23rd, 2011, 09:43 PM »
Season 3 is awesome. It has 'Blink'. Also, never say never.
5750
Plugins / Re: Plugin manager, phoning home and privacy
« on October 23rd, 2011, 09:31 PM »The idea that a server could track what plugins my server says it has doesn't really bother me at all, now if it grabbed other non-plugin related information I could see that being an issue.
The only other aspect I can possibly see causing harm is if a plugin causes a security compromise on a server and someone uses a logged list of servers which has that plugin in order to compromise all of the logged servers.
The only safe option around that is to not provide a list of plugins, and simply request any and all, and filter it client-side. It's not as nice bandwidth-wise (on either side) but it avoids exposing any details the client might have.
I really don't see it being a practical issue for someone else to have a log of plugins, though I suppose that might depend on what exact plugins were on your server and if they themselves were someone how privacy compromises... (in which case I likely wouldn't have them installed in the first place...)
The specific case I'm thinking about is when you have a site that compiles a third-party compendium of packages. There is one such site I know of for SMF, where it provides its own premium mods but also has a large collection of free mods that others have submitted - and I doubt it's that thoroughly vetted. You could add that list (or, as the owner's mods do, add it in automatically) - the problem is you're risking security that way, because while I'm sure we can keep wedge.org from logging anything it shouldn't, we cannot say the same for other sites, so maybe there is some kind of risk there - anyone who could write for a plugin server could trivially enough modify said server.
Maybe I'm being paranoid here, but from a privacy and security standpoint, being paranoid is the way to be...
There is a related concern that most people don't necessarily realise: while we all assume SMF installs are unmodified, it is not unheard of for site owners to modify the setup to not hash passwords.[1]
Can you trust the security of any site you give a password to? (I don't. For sites that I'm not particularly interested in other than support, I either get a test account or create a test account with a deliberately low strength password, and will remove the account when I'm done...)
| 1. | Rare, but it HAS happened. Only once, to my knowledge, but I'd be surprised if it were only the once. |
5751
Plugins / Re: Quick little plugin
« on October 23rd, 2011, 09:17 PM »
I did consider doing that, but in the end I concluded that this plugin is pretty implicitly designed not to be used. It does exactly what it claims to do, which is disable right click. If you know your community is full of technologically disadvantaged users, that's cool, because it'll block them - but that's it.
You should read the readme, it makes it very clear that it does exactly what is requested, except that what is requested doesn't solve the problem, but honestly that's the point.
There's also a comment in the source that simply reads:
Code: [Select]
The plugin exists, primarily, because it's going to be requested. Instead of my going round and telling everyone it's a bad idea and that they're wasting their time, I've made the plugin. If they never read the readme, they're never going to care that they aren't much better off than they were before in terms of copy protection, and if they do, they're going to be a little educated :)
You should read the readme, it makes it very clear that it does exactly what is requested, except that what is requested doesn't solve the problem, but honestly that's the point.
There's also a comment in the source that simply reads:
// If I can't convince you it's a bad idea, I might as well give you enough rope.The plugin exists, primarily, because it's going to be requested. Instead of my going round and telling everyone it's a bad idea and that they're wasting their time, I've made the plugin. If they never read the readme, they're never going to care that they aren't much better off than they were before in terms of copy protection, and if they do, they're going to be a little educated :)
5752
Plugins / Re: Plugin manager, phoning home and privacy
« on October 23rd, 2011, 06:08 PM »
On the subject of logging, I really do think basic details should be logged, like numbers of downloads over time. (Even sm.org does this.) Plus for premium sites it does make sense that the base plugin server is capable of tracking who downloaded what when. I can certainly put a warning in but I think it might detract from people using it, which I don't want to do.
On the whole concept of looking up updates, that could actually be done separately by just requesting a list of plugins and versions available with their required hooks, and letting the client figure out what can be updated. It doesn't have the same privacy issue but the bandwidth use is naturally increased.
That said, if it is simply a list of author:pluginid:version:required-hooks, one per line, that might not be too bad. Still better than requesting a (large) XML block, but it would be done more frequently, I guess, since it would be done daily or so.
Plugins do not currently have any support for "home" servers. I suppose they could provide alternatives but I don't see that it can justifiably replace the home site.
Let me explain. There aren't many use cases for third party sites. The practical applications thereof are premium sites (who won't have their plugins on the core site), people who want to distribute plugins that don't sit well with us, either ones we have moral or practical objections too or that they have issues with us for whatever reason[1], and lastly for sites issuing dev builds.
In all of these cases, there may or may not be overlaps with the core site. For example I might decide to offer some WD plugins that have overlap into the core, and offer them on both sites, and some might choose to only trust the core site even if I specify WD's site there.
The other real case where there's overlay is for dev builds. It might be best to leave the core site for stable builds and offer dev builds through a third party site. In that case you wouldn't necessarily want the third party "home" site to be considered in priority. Though you probably wouldn't offer that as a default server in the package.
I don't really know what to suggest for the best. Would really appreciate input from users who would create plugin servers, who would use plugin servers for premium resources and dev resources etc...
On the whole concept of looking up updates, that could actually be done separately by just requesting a list of plugins and versions available with their required hooks, and letting the client figure out what can be updated. It doesn't have the same privacy issue but the bandwidth use is naturally increased.
That said, if it is simply a list of author:pluginid:version:required-hooks, one per line, that might not be too bad. Still better than requesting a (large) XML block, but it would be done more frequently, I guess, since it would be done daily or so.
Plugins do not currently have any support for "home" servers. I suppose they could provide alternatives but I don't see that it can justifiably replace the home site.
Let me explain. There aren't many use cases for third party sites. The practical applications thereof are premium sites (who won't have their plugins on the core site), people who want to distribute plugins that don't sit well with us, either ones we have moral or practical objections too or that they have issues with us for whatever reason[1], and lastly for sites issuing dev builds.
In all of these cases, there may or may not be overlaps with the core site. For example I might decide to offer some WD plugins that have overlap into the core, and offer them on both sites, and some might choose to only trust the core site even if I specify WD's site there.
The other real case where there's overlay is for dev builds. It might be best to leave the core site for stable builds and offer dev builds through a third party site. In that case you wouldn't necessarily want the third party "home" site to be considered in priority. Though you probably wouldn't offer that as a default server in the package.
I don't really know what to suggest for the best. Would really appreciate input from users who would create plugin servers, who would use plugin servers for premium resources and dev resources etc...
| 1. | Like arantormods existed to distribute plugins without any contribution going back to sm.org |
5753
Plugins / Re: Quick little plugin
« on October 23rd, 2011, 04:55 PM »
It gets upset with the context menu binding to false for some reason, it gives me "Object expected"
The binding on mousedown to false works though. Mind you, the code doesn't bind all mousedown, because I don't want to trap left clicks, and deliberately only indicates prevention of immediate propagation so that normal bubbling still works on left button, or middle button.
The binding on mousedown to false works though. Mind you, the code doesn't bind all mousedown, because I don't want to trap left clicks, and deliberately only indicates prevention of immediate propagation so that normal bubbling still works on left button, or middle button.
5754
Plugins / Re: Quick little plugin
« on October 23rd, 2011, 01:58 PM »
I tried that but IE cried.
As for spoiler bug, I haven't tested it on Wedge but it is a known SMF bug.
As for spoiler bug, I haven't tested it on Wedge but it is a known SMF bug.
5755
Features / Re: New revs - Noob questions?
« on October 23rd, 2011, 03:04 AM »
Well, it's actually from the SMF changelog, seeing how both of us came from SMF development (in different ways) to here:Quote I tend to consider a lot of my changes as 'minor changes' unless they're huge additions or removals. In my case, I almost never use * or & because I almost never touch just those areas when I do anything, but Nao tends to do more subtle things than I do in that respect.
! Minor change or bugfix. (don't bother to log typos except between releases.)
* Change like above, but affects templates.
& Change that affects a language file. (make two if it affects templates too.)
+ Feature addition or improvement.
- Feature or option removal.
5756
Plugins / Re: Quick little plugin
« on October 23rd, 2011, 02:57 AM »
And I'm done. The only real hold-up was trying to figure out the best hook to put this on, and to make sure that I wrote a suitably worded readme file :niark:
(Oh, and while there are some cute scripts out there to do the job, most of the ones I saw briefly in passing do it the old-school way of testing for IE vs NS and expecting anything later to adhere to the NS method, mine however appears to be a bit safer, even if it does use jQuery.)
If you're curious or bored, here's what I came up with.
(click to show/hide)
Any browser not capable of running jQuery is going to have a seriously bad time on the web anyway (we're talking pre IE6 here or fringe browsers no-one has heard of or cares about), so it's not really a problem.
Also, that's disgraceful, I have to write more lines of code to get that one line into the system than I do the code it adds :/
In other news, spoiler has a bug, presumably related to a related bug in SMF pre final (that may still be in final) where a 'you have hidden this post' message won't expand properly if it had code in it because the code's size is not reset properly.
(Oh, and while there are some cute scripts out there to do the job, most of the ones I saw briefly in passing do it the old-school way of testing for IE vs NS and expecting anything later to adhere to the NS method, mine however appears to be a bit safer, even if it does use jQuery.)
If you're curious or bored, here's what I came up with.
Code: [Select] $("body").bind("contextmenu", function (btn) { return false; }).mousedown(function (btn) { if (btn.which & 2 == 2) { btn.stopImmediatePropagation(); } });
It's compact :)
Any browser not capable of running jQuery is going to have a seriously bad time on the web anyway (we're talking pre IE6 here or fringe browsers no-one has heard of or cares about), so it's not really a problem.
Posted: October 23rd, 2011, 02:52 AM
Also, that's disgraceful, I have to write more lines of code to get that one line into the system than I do the code it adds :/
Posted: October 23rd, 2011, 02:52 AM
In other news, spoiler has a bug, presumably related to a related bug in SMF pre final (that may still be in final) where a 'you have hidden this post' message won't expand properly if it had code in it because the code's size is not reset properly.
5757
Plugins / Quick little plugin
« on October 23rd, 2011, 01:59 AM »
OK, tonight's little project is one of those that I'm doing mostly under protest. Which begs the question why I'm doing it at all, and the answer is stupid user prevention.
I would generally rather inform users about the true facts of what they're trying to do, than pander to their ill-informed and frankly dangerous misinformation, but you know users: too many of them are a bit naive.
Tonight's project is one such example: disable right click.
It's useless as plugins go, because it's insanely trivial to bypass it, but you know how some users feel it's useful for protecting their content, and it's one more thing that I can publish, they can find and use and feel happier in its 'glory', or they can download it and then read the readme that covers it in detail. But hey, either way, I've done the best I can.
I would generally rather inform users about the true facts of what they're trying to do, than pander to their ill-informed and frankly dangerous misinformation, but you know users: too many of them are a bit naive.
Tonight's project is one such example: disable right click.
It's useless as plugins go, because it's insanely trivial to bypass it, but you know how some users feel it's useful for protecting their content, and it's one more thing that I can publish, they can find and use and feel happier in its 'glory', or they can download it and then read the readme that covers it in detail. But hey, either way, I've done the best I can.
5758
Off-topic / Re: Doctor Who
« on October 22nd, 2011, 06:09 PM »
Eh, I haven't read all of HDM (I keep meaning to, just never seem to find the time)
5759
Off-topic / Re: Doctor Who
« on October 22nd, 2011, 05:52 PM »
If you're on to season 2, you've already had The Empty Child and the season 1 finale, which are season 1's moments of glory... but season 2 has some very awesome moments.
(click to show/hide)
The Girl In The Fireplace, the Army of Ghosts and Doomsday.
5760
Off-topic / Re: Doctor Who
« on October 22nd, 2011, 05:36 PM »
And more awesomeness on top, yes.