Forum Moderators: buckworks
first of all, i am not a webmaster! but the site i am helping out with DOES have one, and i would like to pass along the info to our webmaster, and also would like to understand the whole process better myself. so if everyone could write in really simple terms, i would really appreciate it :-)
here is the situation:
we are setting up a pay system for an internet radio subscription service. people would pay a monthly fee in order to access the live feed of the radio program and also the access the radio program archives.
this is what we want to happen.
1. person goes to our sign-up page, and clicks on a link to pay for the subscription.
2. person enters their credit card info and is assigned a password. from what i understand, a merchant account can do all this... i read good things about charge.com and will likely go with them.
3. person can now sign in, using their email addy and password, to the subscribers-only area of the website, which will have links that go to both the live streaming of the program and to the archives page. from what i've been able to glean so far, this means that the email address & password is checked against the database of subscribers, and they are allowed or denied access.
the person that was doing this before used oscommerce/php, but i've heard a lot of complaints that it is difficult to use and learn. what is the microsoft version of oscommerce/php and is it easier to use?
what exactly do we need our webmaster to do?
we are lining up a company that will provide the streaming (and give us a link to that streaming) and will store the archives on their file server and give us access to it. so we will have the links to what we need to give to people, but don't know how to set it up so that only people that have paid for subscriptions will be able to access those links.
can one of you brilliant webmasters please explain to me exactly what our webmaster needs to do?
thank you very much!
I recommend a database with three tables:
TableA - Groups
GroupId l RoleName l Destiny
--------------------------------------------------------
1 l Administrator l admin.html
2 l Webmaster l admin.html
3 l BasicSubscriber l member.html
TableB - Member Registration Information
UserId l FirstName l LastName l Status l ExpireDate
---------------------------------------------------------------------------------------
1 Joe l Joey l Active l Sept 01, 3000
2 Joey l Joe l InActive l Sept 01, 2003
3 JoeJoe l EojEoj l Pending l Sept 08, 2004
TableC - Roles
UserId l GroupId
------------------------------
1 l 1
3 l 3
1. Web visitor selects a subscription upon user Member registration. Is taken to payment gateway. Upon payment completion database TableB [Status] is updated to "Active" and Date/Time added to [ExpireDate] for term of subscription.
Only "Active" members can login. During the login process, visitor is authenticated, ExpireDate is checked, then redirected to the appropriate page based upon the assigned role. If ExpireDate is "Today" or their after, member is redirected to a RenewSubscription.html.
2. TableA GroupId is mapped to TableC GroupId. TableB UserId is mapped to TableC UserId.
3. Each subscription belongs to a subscriptions group ( TableA ) . So a group might be "BasicSubscriber" and another group might be "GoldSubscriber".
That's a fast example of how it basically works!
The password issue can be easily solved by "salting" the password fields before hashing them. This is done by adding a second piece of information to the hash that is non-changing and unique for every user – like, for example, the username, or a user ID. Personally, when developing a user database, I normally use a GUID as primary key for the table since it is random and big enough to be used as "salt input" into the hash.
If a user shares the password with others, all you can do is minimize the usage by allowing only one session at a time with the same username/password. If my server shows a US IP address, and an hour later I see the same login but an overseas IP address, I'll contact the original account holder and notify them of the situation and issue a new password etc.
I am a total newbie in database sort of things. I have SMS payment as a standard and now I am trying to figure out credit card systems. The basic idea is the same, people can subscribe with login and password, which can be obtained via credit card or text message.
It seems that this whole thing is going to be too hard for me to put together. What would you recommend me to do? I think I have to hire someone to this.
Most of the thinking has already been done by someone out there. Starting with the language you want to use for development search google for script examples. If you know which credit card processor your going to use, check their web site to see what they may provide for code samples. Some processors will generate the Username/Password for you.
If time IS a factor, there are lots of web sites that provide complete membership management systems (example: MemberGate). Hotscripts is a great place for scripts in nearly every development language.
[edited by: DaveAtIFG at 2:28 pm (utc) on Sep. 12, 2004]
