I'd agree with the cron job approach. You probably only need to run it once a day - check your analytics/logs for your quietest periods.
However, you could do this with or even without a cron job, as AHG goes on to suggest - with DateTime(). However, I recently noticed a problem with this. If you're developing on a local Windows machine, unless you have a php VC9 build, you may find that certain formats will not work (specifically the 'a' format) with the diff.
diafol
Keep Smiling
10,672 posts since Oct 2006
Reputation Points: 1,632
Solved Threads: 1,514
Skill Endorsements: 57
You can also use mysql events for triggering (v >= 5.1). I have actually never used them so do not know the deatils.
broj1
Nearly a Posting Virtuoso
1,212 posts since Jan 2011
Reputation Points: 167
Solved Threads: 164
Skill Endorsements: 13
I don't think you need to use general update on all users - you could just target users that try to log in. On successful login - if they are beyond the subscription time - update their record to 'EXPIRED' and allow them a facility to renew the subscription. An user with EXPIRED status should not be able to gain access to the general pages, just the renewal page. You can control access with a session variable, e.g.
session_start();
//check DB for subscription expiry - if expired but status set to ACTIVE, update DB status filed to EXPIRED. Set $_SESSION['active'] to false. Likewise if the status field shows EXPIRED, set $_SESSION['active'] to false. Redirect the user to the renewal page.
All other 'active' pages control access against the $_SESSION['active'] variable, e.g.
session_start();
if(!isset($_SESSION['active'])){
header('Location: index.php'); exit; //or wherever you want all unlogged members to go
}elseif(!$_SESSION['active']){
header('Location: renew.php'); exit;
}
Perhaps not the most elegant of solutions, but it should allow you to control access without having to run a cron job or an event. Naturally the 'status' field could just show 0 or 1 - doesn't have to be varchar. Also, without a cronjob, you won't be able to send email reminders to renew subscription very easily.
diafol
Keep Smiling
10,672 posts since Oct 2006
Reputation Points: 1,632
Solved Threads: 1,514
Skill Endorsements: 57
I agree, checking subscription time upon successful login and doing appropriate action is all you basically need to do to handle this. Additionally you can still do separate periodical checks to maybe warn users by mail about their subscription end approaching.
broj1
Nearly a Posting Virtuoso
1,212 posts since Jan 2011
Reputation Points: 167
Solved Threads: 164
Skill Endorsements: 13
Well that's easy enough - reject the login if the subscription has expired.
I'm unsure of your system - could you expand a bit on that? Distrubted or hosted (by you). Do you have many clients who log into the one system? Are these cleints related to one company or not? I.e. Do you want to block all users of one company if the company's subscription has expired.
diafol
Keep Smiling
10,672 posts since Oct 2006
Reputation Points: 1,632
Solved Threads: 1,514
Skill Endorsements: 57
At login of each user:
- check what the user's company is
- if the subscription has expired run the update query for all the users from that company, something like:
mysql_query( "UPDATE USERS SET STATUS='LOGGED_OFF' WHERE company='$company'";
broj1
Nearly a Posting Virtuoso
1,212 posts since Jan 2011
Reputation Points: 167
Solved Threads: 164
Skill Endorsements: 13
WRT subscription and distributed packages - you may find it difficult to stop somebody using you stuff once the registration period is over. Anybody with access to your php code can alter it to make it work, e.g. duplicate your DB, change DB settings, remove licensing restrictions, etc. You might then have to enter the murky world of encrypting.
diafol
Keep Smiling
10,672 posts since Oct 2006
Reputation Points: 1,632
Solved Threads: 1,514
Skill Endorsements: 57
Encryption will mean having to encrypt all your php. This will probably need to be a paid service. IonCube is probably the best well known. I think Zend also offer this service. Not for the faint hearted.
If you are going to sell this service to customers, you may be better off hosting it yourself on a dedicated / managed server. The cost is greater than shared hosting, but that may be offset somewhat by the cost of encryption and redistribution of updates.
Updating your hosted service would be easier. You don't want to be supporting clients with their own server configurations related to your installation. Just a thought. Both approaches have their pros and cons.
diafol
Keep Smiling
10,672 posts since Oct 2006
Reputation Points: 1,632
Solved Threads: 1,514
Skill Endorsements: 57
You could always setup a client portal and use cURL / REST to access your online data. You could make it so that they have to send their security keys in the url. Your DB can then check if you need to honour the call or not.
diafol
Keep Smiling
10,672 posts since Oct 2006
Reputation Points: 1,632
Solved Threads: 1,514
Skill Endorsements: 57