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 - markham
61
The Pub / Re: Reminders, CAPTCHAs and registered users
« on May 16th, 2012, 07:17 AM »So, there's the question: should you be able to call the reset-password stuff if you're logged in, and if not, how should you be able to reset it from inside the profile area, since you can't change your password if you can't remember your current one?
As a related thought, maybe a plug-in could be developed that adds a new field to the user's profile and a required question to the registration page basically asking "Do you access using (a) your private computer or (b) through a friend's or public-access computer?". If the answer given is "b", then always limit the online session to a maximum of x minutes (where X is an admin-specified value).
62
The Pub / Re: The Cookie Law (in the UK at least)
« on May 6th, 2012, 12:23 PM »Can't wait for the US to get into these laws should be an interesting clusterf*ck.
| 1. | Eg as expressed on SMF for example |
63
The Pub / Re: The Cookie Law (in the UK at least)
« on May 4th, 2012, 07:42 PM »
You replying to my post on SMF reminded me - did ICO ever reply to your well thought-out email? If so, was it quite simply the web equivalent of RTFM? ::)
My reason for posting an implementation of geoIP functionality to determine if the use of cookies needs visitor approval or not was twofold:
My reason for posting an implementation of geoIP functionality to determine if the use of cookies needs visitor approval or not was twofold:
- I'm a 60+ year-old non-programmer (by your standards!) and am completely self-taught. I've never written a line in PHP before and I wanted to see if I could do it and make it work. The result is probably very amateurish but it does work as advertised.
- There is quite some hostility and resistance to this law generally being expressed in various SMF threads and I thought that this might possibly encourage those EU-based Admins who are concerned at not pissing-off their non-EU visitors into actually making their sites compliant. Of course it's entirely up to them if they choose to implement the geoIP side with the attendant risks that has.
64
The Pub / Re: The Cookie Law (in the UK at least)
« on April 27th, 2012, 03:23 PM »The IP address used is the one the webserver itself received - if it's behind a firewall it might be the internal IP rather than an external one. It's... complicated.Quote Yes that is the IP Address my ISP tells you I'm on, but according to my desktop gadget, my external IP is 120.28.248.151 - go figure!Thanks, though I really wanted a link so I could see them in action before I looked at any code. It's not always practical to study code to see the result you will get from it ;)Still, always good to have the code handy.Quote To save you rushing over there, I'm attaching both to this post.
65
The Pub / Re: The Cookie Law (in the UK at least)
« on April 27th, 2012, 02:45 PM »Funny, in the screenshot you posted, it was using your IP address - but it'll go with a hostname if it has that available. The idea is to validate that when content is posted, that it's come from the same source as the person getting the form (so that you don't get the same amount of pump and dump spam)Quote What's interesting about that cookie is that if you inspect it in Firefox, it contains the name of the ISP you're connected via. That's what led me to believe it was being set by an ISP.
Got a link? There's certainly nothing that says the consent has to be shown every page and nothing that says it can't be set via JavaScript, so I can well believe it is compliant but I'd like to see it to get a sense of what the ICO is claimed to have agreed with.Quote Incidentally, Wolf Software (UK) has a neat javascript GPL implementation requiring only a slight modification to the page header. The company claims it has consulted with ICO to ensure its solution fully complies with the law.
To save you rushing over there, I'm attaching both to this post.
66
The Pub / Re: Database Backup, Restore and Repair
« on April 27th, 2012, 01:42 PM »
How about MySQLDumper (from SourceForge)?
67
The Pub / Re: The Cookie Law (in the UK at least)
« on April 27th, 2012, 01:36 PM »Well,bb2_screener_ is set by Bad Behaviour. I'm aware of that cookie and have chosen not to implement it into the implementation that's in Wedge, so that's not an issue.
But that's rather unpleasant that you're getting injected cookies like that. Not using Google Adsense, I take it?
Incidentally, Wolf Software (UK) has a neat javascript GPL implementation requiring only a slight modification to the page header. The company claims it has consulted with ICO to ensure its solution fully complies with the law.
68
The Pub / Re: The Cookie Law (in the UK at least)
« on April 26th, 2012, 07:55 PM »
I've just noticed something rather alarming. If your site permits Google Analytics to set up to four cookies (__utma, __utmb, __utmc and __utmz) it appears you are also inviting Google to set further cookies. I only discovered this by accident and these cookies are not listed in Firefox but are by Chrome's "inspect elements" (I actually use SW Iron, a Chromium-based browser which has none of the "phone home" stuff that Google has in Chrome).
As you can see, the four cookies I've highlighted have not been set by my site but by Google. I'm not in the UK at the moment so I don't know if Google is using geoIP to determine whether or not to ask permission before setting these cookies, but as they are being set via my site, I'm a tad concerned as to who is responsible. (The other "odd" cookie, bb2_screener_, is set by my ISP and is used, I think, for traffic-shaping purposes.)
I wonder if the ICO is aware of this.
As you can see, the four cookies I've highlighted have not been set by my site but by Google. I'm not in the UK at the moment so I don't know if Google is using geoIP to determine whether or not to ask permission before setting these cookies, but as they are being set via my site, I'm a tad concerned as to who is responsible. (The other "odd" cookie, bb2_screener_, is set by my ISP and is used, I think, for traffic-shaping purposes.)
I wonder if the ICO is aware of this.
69
The Pub / Re: The Cookie Law (in the UK at least)
« on April 26th, 2012, 06:00 AM »OK, so let's back up a minute.
The PHPSESSID cookie, left alone and untouched by logins, will be removed properly. When logging in, though, SMF and Wedge both make that a persistent cookie. There's no argument on that score: it's a persistent cookie that is not being handled nicely and certainly flies in the face of any argument we can make that PHPSESSID is a valid session cookie when it stops being one.
@nend, why should you bother? That's a good question, and for now I don't think you have to be too concerned if you're based entirely outside the EU. That assumes the US do not introduce any forms of sanction, and I wouldn't put it past them, because then a user in the EU could complain to their national body and they can take it forward on that user's behalf. So in that respect, you don't have to be too bothered - for now.
Assuming the ECL cookie is set, there is nothing in the guidance about it being a session cookie from what I remember, and it does seem overly onerous to make it such, particularly if there is a persistent cookie of any form present.
My take on it is that if cookies are provided that the site is expecting (e.g. the member cookie or PHPSESSID), we can assume that consent must have been provided in the past and not require that extra cookie.
The ECL cookie should be persistent, in my opinion, for the simple reason that the SMF member and PHPSESSID cookies could get removed at the end of a session[1] should the user select a session length shorter than "forever".
As an amusing aside, I followed a link provided by the ICO in its guidance document. The link is to a US-hosted site, ]allaboutcookies.org and immediately upon landing on its home page, a nice JScript popup informs you that it would like to set a cookie - for advertising - and gives you some options; very nicely done. The problem is that its popup window doesn't include any details of the first-party cookie it wants to set and that cookie is set regardless! I was left wondering whether the ICO should really continue promoting "allaboutcookies" since its implementation of the new regulations is somewhat lacking!
| 1. | But that assumes that the browser makers get their act together and actually removed expired and session cookies! |
70
The Pub / Database Backup, Restore and Repair
« on April 25th, 2012, 06:24 AM »
Yesterday we learned that SMF's database backup "feature" is somewhat of a mixed-blessing - and I'm being polite here. Apparently the backup files may not necessarily be complete - contain all the records for all the tables. As it stands it serves little more than provide a false sense of security.
As I understand it, that feature was added to help those on free hosting where there may be a limited host Control Panel that doesn't include MyphpAdmin which would otherwise be used to backup and restore databases. But since SMF doesn't include a "restore" counterpart, it's all a bit half-arsed.
Now I do, I think, understand why the backup could fail and if I understand correctly, it's all about maximum execution times. But that surely is down to bad design in the first place?
Here's an idea for you. Would it not be better to have a backup system that runs in background via a scheduled task and rather than emitting a SQL "dump", it outputs table structures and data in XML format. It could do this table by table either as a complete backup or as a partial - all records added from a given date - thus allowing for incremental backups (but I do recognise that may entail time-stamping all records which may not be desirable). A complementary "restore" system would then simply prompt for a (compressed) backup file which is then decoded and updates the database. As both backup and restore would process manageable "chunks" of data, obtained via queries, the maximum execution time limit should not be exceeded.
Or am I being naive and overly simplistic? Forgive me if I am, please.
I mentioned "Repair" in the title for a reason. Would it be possible for Wedge to inspect its various tables and remove records that are incomplete or appear logically to be extraneous? My reason for asking this is simple: I appear to have a number of extra rows in the Aeva Permissions area - ie sets of permissions for membergoups that don't exist and have no membergroup name assigned and I don't know if I can safely remove them (and the only way I can see of doing that would be to edit the SQL to remove them, put the site into maintenance mode, delete that table and recreate it at the server level).[1]
I do appreciate that an analysis/repair function is a bit of a tall order and not really necessary as a core function - although backup/restore arguable should be - and best dealt with by a plug-in.
Again, my apologies if I'm being a prat!
As I understand it, that feature was added to help those on free hosting where there may be a limited host Control Panel that doesn't include MyphpAdmin which would otherwise be used to backup and restore databases. But since SMF doesn't include a "restore" counterpart, it's all a bit half-arsed.
Now I do, I think, understand why the backup could fail and if I understand correctly, it's all about maximum execution times. But that surely is down to bad design in the first place?
Here's an idea for you. Would it not be better to have a backup system that runs in background via a scheduled task and rather than emitting a SQL "dump", it outputs table structures and data in XML format. It could do this table by table either as a complete backup or as a partial - all records added from a given date - thus allowing for incremental backups (but I do recognise that may entail time-stamping all records which may not be desirable). A complementary "restore" system would then simply prompt for a (compressed) backup file which is then decoded and updates the database. As both backup and restore would process manageable "chunks" of data, obtained via queries, the maximum execution time limit should not be exceeded.
Or am I being naive and overly simplistic? Forgive me if I am, please.
I mentioned "Repair" in the title for a reason. Would it be possible for Wedge to inspect its various tables and remove records that are incomplete or appear logically to be extraneous? My reason for asking this is simple: I appear to have a number of extra rows in the Aeva Permissions area - ie sets of permissions for membergoups that don't exist and have no membergroup name assigned and I don't know if I can safely remove them (and the only way I can see of doing that would be to edit the SQL to remove them, put the site into maintenance mode, delete that table and recreate it at the server level).[1]
I do appreciate that an analysis/repair function is a bit of a tall order and not really necessary as a core function - although backup/restore arguable should be - and best dealt with by a plug-in.
Again, my apologies if I'm being a prat!
| 1. | I am not asking for support for Aeva here, it's up to me to sort this out best I can, but merely mention this as a live example of why an analysis/repair module would be a desirable feature. |
71
The Pub / Re: The Cookie Law (in the UK at least)
« on April 24th, 2012, 07:24 PM »Just went over the code changes and the found the source on github, Your right, It looks like it shouldn't cause any problems. The ecl warning script just checks to see if a cookie is set that it added before and returns true or false. ;)
On the off-chance that browser companies fix that, I have modified my version of the code so that the script sets a persistent (6 year) cookie and that it only checks for that one cookie.
72
The Pub / Re: The Cookie Law (in the UK at least)
« on April 24th, 2012, 06:55 AM »I suppose for google analytic's you could also just put this before it in the head.
Code: [Select] if (!ecl_authorized_cookies())
// Google Analytics Integration
function ob_google_analytics($buffer)
{
global $modSettings, $boardurl;
if (ecl_authorized_cookies())
{
/*
if (!empty($modSettings['googleAnalyticsCode']) && !isset($_REQUEST['xml'])) {
$google_code = '
<script type="text/javascript"><!-- // -->' . chr(60) . '![CDATA[' . '
var _gaq = _gaq || [];
_gaq.push([\'_setAccount\', \'' . $modSettings['googleAnalyticsCode'] . '\']);
_gaq.push([\'_trackPageview\']);
(function() {
var ga = document.createElement(\'script\'); ga.type = \'text/javascript\'; ga.async = true;
ga.src = (\'https:\' == document.location.protocol ? \'https://ssl\' : \'http://www\') \'.google-analytics.com/ga.js\';
var s = document.getElementsByTagName(\'script\')[0]; s.parentNode.insertBefore(ga, s);
})();
// ]]' . chr(62) . '</script>';
*/
// add in the analytics code at the very end of the head section
$buffer = substr_replace($buffer, $google_code . "\n" . '</head>', stripos($buffer,
'</head>'), 7);
}
}
// All done
return $buffer;
}
Also reading a lot of discussion about it. It does seem like these big company's might not be taking this serious.
Maybe its my hoping in chance that it will get challenged and thrown out.
I mean who wants to be throwing alerts at people to accept, lol..
I'm not saying I don't agree with the new law, but I certainly think its should be looked at again and properly, probably in my favour LOL.
Edit: I would just like to add.. The cookie that is set from the mod is only supposed to last for that "session" I don't think there is a need to keep throwing it at the users face every time they revisit.
If my understanding is correct, they only have to agree to it once.
setcookie('ecl_auth', 1, 0, '/');
setcookie('ecl_auth', 'EU Cookie Law - LiPF cookies authorised- ' . strftime('%d-%b-%Y %H.%M.%S', time()), time() 189345600, '/'); // Set a 6 year cookie, the same as a "Forever" cookie in SMF
| 1. | That information string contains HTML entities and I'm not sure if (a) that is safe and (b) how to overcome it. |
73
The Pub / Re: The Cookie Law (in the UK at least)
« on April 24th, 2012, 06:20 AM »How about us that operate and live in the US and decide to ignore the foreign law. I shouldn't be expected to follow by a law that I am in no way bound by, should I?
*edit, this system also helps reduce server load. Hopefully you didn't disable it, the mod IMHO is useless without this system in place because it can bring your site to a slow down. It is hard to remember everything from back then, lol.
Changing its index.php file was actually very simple - even for a 61 year old non-programmer like me!
define('SMF', 1);
// Experimental Optimizer
define('loadOpt', 1);
// Lets go head and load the settings here.
require_once(str_replace('//','/',dirname(__FILE__).'/').'../Settings.php');
// Load SMF's compatibility file for unsupported functions.
if (@version_compare(PHP_VERSION, '5') == -1) {
require_once($sourcedir . '/Subs-Compat.php');
}
//
// Load Emanuele's 'EU Cookie-checker Modification.
require_once($sourcedir . '/Subs-EclWarning.php');
// If the user hasn't accepted cookies, get out! We can not go ahead and load SA-Chat
// because set_session() sets cookies and so potentially does SA-Chat's javascript.
if (!ecl_authorized_cookies())
die();
// Okay, cookies can be set so continue.
session_start();
session_cache_limiter('nocache');
//<-------------------------------------------------------------------------------
// Load the theme
if (isset($_REQUEST['theme']) && !strstr('..', $_REQUEST['theme']) && is_file('./themes/'.$_REQUEST['theme'].'/template.php') && is_file('./themes/'.$_REQUEST['theme'].'/style.css')) {
$themeurl = $boardurl.'/sachat/themes/'.$_REQUEST['theme'];
$themedir = $boarddir.'/sachat/themes/'.$_REQUEST['theme'];
$thjs = 'theme='.$_REQUEST['theme'].'&';
require_once($themedir.'/template.php');
}
74
The Pub / Re: The Cookie Law (in the UK at least)
« on April 23rd, 2012, 05:47 AM »
Just as an aside, in my view the Cookie Law is actually completely unnecessary in the UK at least. Just after the Parliamentary Christmas break (1989), MP Micheal Colvin introduced the Computer Misuse Bill which although somewhat watered-down came into force mid-year 1990. Cookies are actually covered under Section 3 of the Act which deals with "unauthorised modification of computer material". Unless accepted, a cookie is arguably an unauthorised modification. And the World Wide Web was in gestation at the time.
However we are where we are and there's one scenario that hasn't been mentioned to date. Suppose Nao crosses the Channel and goes to Arantor's new home on a visit. Whilst he's there, he asks Arantor if he can use his (Arantor's) PC to check his Forum - and we'll assume, for the sake of argument, that Arantor is not a member of that Forum. Nao lands on the Home Page and is asked to accept cookies which he does. He then logs-in and because its the default, his session time is set for 6 years. He logs-out and closes the browser which should (but doesn't always) delete the Session Cookie; his "member's" cookie - along, possibly with GA's four - remain in Arantor's browser Cookie "jar".
A few weeks later, Arantor notices that a web site he's never heard of nor visited has set cookies. (Let's not get into a debate as to whether or not Nao should have consulted Arantor prior to accepting the cookies, we'll assume they were both engrossed in what they were doing at the time.) Having noticed these Cookies, Arantor decides to lodge a complaint with the ICO. Cookies were set but HE didn't authorise them and it's entirely possible that ICO might ask awkward questions of the site owner.
A similar situation pertains in the case of Internet Cafes.
So maybe it's not enough for a web site owner to get a visitor to simply click on a link to signify acceptance of cookies. Maybe the visitor should be asked to give some means of identification (but that raises other data and privacy protection issues).
However we are where we are and there's one scenario that hasn't been mentioned to date. Suppose Nao crosses the Channel and goes to Arantor's new home on a visit. Whilst he's there, he asks Arantor if he can use his (Arantor's) PC to check his Forum - and we'll assume, for the sake of argument, that Arantor is not a member of that Forum. Nao lands on the Home Page and is asked to accept cookies which he does. He then logs-in and because its the default, his session time is set for 6 years. He logs-out and closes the browser which should (but doesn't always) delete the Session Cookie; his "member's" cookie - along, possibly with GA's four - remain in Arantor's browser Cookie "jar".
A few weeks later, Arantor notices that a web site he's never heard of nor visited has set cookies. (Let's not get into a debate as to whether or not Nao should have consulted Arantor prior to accepting the cookies, we'll assume they were both engrossed in what they were doing at the time.) Having noticed these Cookies, Arantor decides to lodge a complaint with the ICO. Cookies were set but HE didn't authorise them and it's entirely possible that ICO might ask awkward questions of the site owner.
A similar situation pertains in the case of Internet Cafes.
So maybe it's not enough for a web site owner to get a visitor to simply click on a link to signify acceptance of cookies. Maybe the visitor should be asked to give some means of identification (but that raises other data and privacy protection issues).
75
Off-topic / Re: French election
« on April 22nd, 2012, 08:20 PM »A statistic that gets trotted out every French election is that, by registered French voters, London is France's 6th biggest city :)So we always get a visit from the candidates.