How to control membership duration with php?

[dbalas]

Hi all!

I am creating some stock management system and i would like to offer subscription (monthly/yearly). I need help in controling that...

Dont know what would be the right way to do that...

Anny ideas?

Maybe to make a php script which will delete users passwords from the database in 365 days after first login?

[Octet]

The simplest way I can think of would be to record the date when the user was registered. Depending on how accurate you want it shall depend on whether it is recorded to the day, hour, minute or even second.

As PHP scripts require a trigger, you cannot leave it running in the background. If it isn't vital then you could leave it to when they log in again, so if it has been 365 days since it was created then it checks the difference. This reduces the strain on your server however it does mean that it doesn't actually delete on the 365th day.

Another method would be to run what is called a 'cron job', cronous being the Greek God of time. This is a bash script which runs on the server and triggers at a specific time. This means that you can trigger it hourly, every half an hour etc. The only issue is cron's don't work very well in times less than 5 minutes so it depends on your accuracy, and obviously triggering it every 5 minutes is going to cause a lot of work for the server.

Good luck and I hope this supplies the basics, to work out the time difference using PHP you could then use the DateTime_Diff function: http://www.php.net/manual/en/datetime.diff.php

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.

[dbalas]

Hi!

Thank you for your answers! I found this solution

mysql_query( 'UPDATE USERS SET STATUS = \'LOGGED_OFF\' '.
               // whose last action was more than 14400 seconds ago (4 hours)
               'WHERE (CURRENT_TIMESTAMP() - TIMESTAMP(LAST_ACTION)) > 14400' ); 

so if i rewrite this to suite my needs, like for example that in 31536000 seconds (one year) updates databae field in which the login page is called from and revirites it to echo instead login page you subscription is expired. Of corse, i would encrypt login page which would make this query.

What do you think? Too complicated or impossible? :)

Thank you!

[Octet]

That should work, however you shall still need a trigger and I would suggest updating it to the new MySQLi extension.

(note, remember to mark the thread as solved once you've got it working :D)

[broj1]

You can also use mysql events for triggering (v >= 5.1). I have actually never used them so do not know the deatils.

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.

[broj1]

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.

[dbalas]

Hi!

Thank you all!

But i dont want to block one subscriber. I want to block whole system with it. Since it will be a warehouse management system, i need to block whole system so no one can log in.

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.

[dbalas]

I have system that is hosted by me (for now). I have few clients from one company that are using the system. For now it is under mine conrol but after they test it i will try to sell it to more companies. If the subscription is over, i want to block whole system for the whole company. I can do it now easy with login to server and blocking it there... But i want to know how can i do it automatic after certain period of time.

[broj1]

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'";

[dbalas]

Thank you all for suggestions.

I think i will run query to check current date and subscription start date and redirect based on the result... If time difference is bigger than 365 days redirect to renew page, else redirect to login page...

Will post code when i finish.

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.

[dbalas]

Something like i think index page should look like... Does this make any sence?

<?php

(connect to database)

    mysql_query( 'SELECT subscription_date, Last_login FROM some_table' );


$sd = subscription_date;
$ll = last_login;
$t = 31104000;

if ($ll - $sd < $t)

  header("Location: login.php");

} else {

  header("Location: index.php");

}

?> 

subscription_date and last_login are booth timestamps and time is in seconds.

And on login page i put index request in case someone goes directly to login.php. Than i encrypt both pages (index.php and login.php)...

Im sure the code needs more work and need to test it :) but just to show you what i mean. Is that going in the good direction or?

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.

[dbalas]

Yea, i agree with you. That is how im dong it right now, im hosting it everything on my server because i want to have full control over it. I was just thinkng if i ran in to a client that wants to have it hosted localy inside the company on their server what could i do to protect it... Will search around a bit more.

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.