I'm selling my Windows application over my website. I'm using Paypal and LibertyReserve as my payment processors. I created checkout buttons to automate the purchase process. After the purchase is complete, the buyer is redirected to a thank you page.
I'm issuing a serial and a download link after the checkout is complete. I'm currently doing it by using PHP, but it's not secure.
I have a text file with some 100 serials in it. Every time the user visits the thank you page, PHP script checks if the cookie is not set (to avoid repeated visits). If the cookie is not set, it opens the text file with the serials, reads the first serial and stores it in a cookie. The serial is deleted from the text file. After that, user is redirected by using "header" to the final page where it shows the cookie content and says "This is your serial key: [cookie value containing the serial goes here]".
Now, everyone with a bit of brain can just read the whole text file with the serial keys. How can I secure this/make it better?
Any suggestion will come handy. Thanks!
Store every serial code in MySQL database, table could be like this:
id, serial, purchased, date, hashcode
When user comes back from paypal with success payment, you will redirect him to something like serial.php?hashcode={hashcode} script which retrieves serial number by hashcode and print it to user. Script will also set serial row as purchased and if you don't want to allow user to see this page second time you can do it.
You have a table with all the serial keys.
+--------+-----------+
| id | serial |
+--------+-----------+
| 1 | 123-45 |
+--------+-----------+
| 2 | 456-43 |
+--------+-----------+
When a transaction is executed, and you have an unique identifier for the transaction, you would have another table that holds what serial id belongs to the unique identifier.
+--------+-----------+-----------+
| id | trans | serialId |
+--------+-----------+-----------+
| 1 | 654326 | 1 |
+--------+-----------+-----------+
| 2 | 876430 | 2 |
+--------+-----------+-----------+
The serialId/trans column are unique so no two transactions could ever have the same serial id.
Related
I am designing a system where I have multiple shops where each shop should have its own set of sequential numbers for its invoices. Obviously my primary ID column will be sequential for all invoices in the system so obviously I will need another column to store this "shop specific" invoice number. What is the best manner to store and get the next ID for this shop specific number? For example would it be safe to simply get it right from the invoices table doing something like: SELECT MAX(INV_NUM) FROM INVOICES WHERE SHOP_ID = # and add one, and subsequently create the new invoice record? Or would there be issues with the timing if 2 instances of my script were to run at the same time? For example the first script fetches the next ID, but before it gets the chance to create the new invoice record the second instance requests the next ID and gets the same one as the first script... I was then thinking about just storing the last used number in a separate table and as soon as I request the next invoice number immediately write the new next order number and persist it so that the time between fetching the next order number and creating the record that the next request would rely on is kept to an absolute minimum... literally 3 lines of code:
$nextId = $shop->getLastId() + 1;
$shop->setLastId($nextId);
$em->persist();
Invoices
------------------------------
| ID | INV_NUM | SHOP_ID |
------------------------------
| 1 | 99 | 1 |
| 2 | 100 | 2 |
| 3 | 100 | 1 |
Shops
-------------------
| ID | LAST_ID |
-------------------
| 1 | 100 |
| 2 | 100 |
If you're using Doctrine, which I assume you are since you're using Symfony then you can lifecycle events to listen for changes in your entities. Before saving you can then update your second column to the incremented value.
Regarding race conditions, to be sure you don't have bad data in your database you can put a unique constraint on your shop ID and invoice number.
I am working on a shopping cart website,
I created a table to display to the user tp order like this:
+---------------------------------+
| My order list |
+----+------------+---------------+
| ID | NAME | ACTIONS |
| id | name | update delete |
| id | name | update delete |
+----+------------+---------------+
The problem is I identify the edit item like this:
mydomain.com/product_list/edit/1
Where 1 is the table ID of the product list
It is really dangerous as other user can delete the records of other by trying to tamper the id. How to secure this one? Even by posting, the hacker can just create a fake posting page, and post the fake id to the program.
Thanks
I've read your question and comments. And I think storing owners of tables in another table can help you (if I get you right)
You said
since the order id is just by number , e.g. order id 1 is the first record for customer A , order id 2 is for B, 3 for A etc... so if user B type in / post 3 as parmeter then he can delete the record of user A
Before you let me alter the table, you have to check if I've permissions for this. You can check my e-mail, my password, add them to session etc. But when it comes to check query string, you can simply look if this table is one of my tables.
So if user B type in / and post 3 as parameter, you can go and check if B is one the owners of table 3. If no, don't let B do anything.
I want to put a hit counter or visits to display for my website http://www.deerpages.co on every dynamic pages. I'm using Php and MySQL. But, I'm thinking of once I've put every tracking in per row inserted, then that table will be full soon.
Is there any external ways we can do this? I mean, like Google Analytics or Alexa type of trackings? and can be able to display them?
Any help would be appreciated.
Thanks a lot!
When you put a page counter on content, you change the value of the counter in your database, not insert a new row for it each time.
Assuming your table looks something like this:
contentTable
+------+---------+
| ID | Counter |
|------|---------|
| 1 | 35 |
| 2 | 54 |
+------+---------+
You can update the row with ID of 1 like this:
update contentTable set Counter=Counter+1 where ID=1;
Assuming that you link each page to an ID in the database. You can also easily keep all your content in the same database table.
Edit:
If you want to store other data about each visitor, then make a separate hitCounter table along the following lines:
CounterTable
+----+---------+----------+---------|
| ID | Counter | HTTP_REf | Country |
|----+---------+----------+---------|
| 1 | 46 | SomeData | USA |
| 2 | 28 | Data2 | Aus |
+----+---------+----------+---------+
And update the data as required based on the users individual data columnsm such as:
insert into counterTable (ID, Counter, HTTP_Ref, Country)
values (null, 1, '".$HTTP_REF."', '".$country."')
On Duplicate Key update set counter=counter+1;
(Assuming Keys of ID, HTTP_Ref and Country)
Having said that, I would suggest either looking at using some space on the database (really, you will need a LOT of hits to "fill up the tables" as such) or maybe simply split the basic counter with a stats table that lists Country, Referrer and the like into different tables.
I want my users to activate their accounts before they are able to login. They are sent an email after registration containing an activation link, something like this:
http://www.blabla.com/activate.php?email=blabla#blabla.com&token=Aisd23uNMAu53932asdDasd82AS
Of course, whenever someone logs in, I have to check wether or not that user has activated his/her account. I can think of 2 ways to solve this problem, either have an extra column in my 'users' table, which is set to empty whenever a user activates like so:
-----------------------------------------------
| id | username | password | activation_token |
-----------------------------------------------
| 1 | user1 | blabla | |
-----------------------------------------------
| 2 | user1 | blabla | asd232DA34qADJs2 |
-----------------------------------------------
Then I extract the activation_token along with the user-information whenever a users logs in. Or I could have a seperate table that contains activation tokens only, which is then joined on the 'users' table everytime a user logs in:
--------------------------------------
| id | account_id | activation_token |
--------------------------------------
| 1 | 37 | dsad2428491dka98 |
--------------------------------------
| 2 | 2 | asd232DA34qADJs2 |
--------------------------------------
So which one would be most efficient? Thanks for your time.
EDIT: Thanks for all the great responses
Personally, I'd do a combination of the two...
-------------------------------------
| id | username | password | status |
-------------------------------------
| 1 | user1 | blabla | 1 |
-------------------------------------
| 2 | user1 | blabla | 0 |
-------------------------------------
Where the status is a TINYINT(1) field which is 0 for deactivated users, and 1 for activated users. That way, you can tell really quickly the "status" of the user...
Then, store the token in another table (just like you already have)... That way, you don't need to join, or check a string column when not activating the account...
Use the first option - add an isactivated column to the USERS table.
There's no need for a separate table - this is a one-to-one relationship.
Storing the token in the Users table rather than a seperate table will mean that you don't have to join them during each query, which will be slightly quicker.
Also, you're not storing the userIds and creating a new Id for that tokens table, which will save on the data storage.
I would have an integer field, Activated, that is defaulted to 0. When someone attempts authentication, you would only look for Activated accounts. I store auth tokens in a separate table like you have described.
If the relationship is 1-1 (e.g. the activation table would have 1 row per account id), then doing a fully normalized 2-table approach is an overkill.
You would not have major problem with either approach but 1-table one is easier.
If you go with 2-table approach, you should store "activated" yes/no flag in the user table, so you don't need to join to a second table for user login purpose.
If the activation token is only ever used to validate the 'click here to activate your account' link and is never used again, then there's no point in wasting space in your user table storing the char(32) (or whatever it is) field for a one-time usage. Put the activation tokens in a seperate table that your account activation script can refer to when the user clicks through to activate. Once the activation's completed, you can delete the token's record from that seperate table.
Put an 'is_activated' boolean/bit field in the user table that your login script can check during the login process (and output a "hey, you haven't activated yet" error if the field's null/false).
Of course, disk space is cheap these days. Even a million users each with a 32char activation token will only 'waste' 32meg of space. With a terabyte drive going for less than $100, that's 0.00305% of the disk, and essentially $0.00 cost (0.305 cents).
I don't think there's a need to store the activation token in DB. Something like md5('users#email' . 'secret') will work just fine. As for user status, i agree with others, use a separate dedicate "status" column in the users table. An additional advantage is that this column can store others stati as well (e.g. "banned" ;)
In my opinion instead of activation code being stored in users table, keep a flag set it off by default. when a user clicks on any activation link, then update the table and set the flag on.
Before logging in check the flag is on or not.
If flag is off then the user has not clicked on the activation link. then you can give a error message to the user.
If flag is on then the user can log in successfully.
I have a website that allows users with accounts. Account profiles are displayed on the front end of a website. Users can login and update their data, but it all must be approved by an admin (on a form) before the front end content reflects their update. The "live" data is stored across multiple tables in a Postgresql DB.
I'm looking for ideas for the (best / easiest) way to handle storing (db schema) this updated data that will allow an admin user to
approve/deny updates independently for a user (approve update A, deny update B, and ignore update C)
Be easy to maintain
Be easy for me to pull the updates to show admin and then process each individual field request.
Admin will need to be able to see a list of all users that have pending updates and then be able to see which fields for a specific user was updated so they can approve/deny the request.
Users can freely update a field as many times as they want, but admin will always see the current field content and the last update the user made.
I don't need to be able to see exact differences (although brownie points if you know how). They really just need to be able to see the two fields
ie:
Current Update
+--------------+-------------+-------------+
| | | (o) Approve |
| description | Description | |
| | | (o) Deny |
+--------------+-------------+-------------+
| | | (o) Approve |
| title | Title | |
| | | (o) Deny |
+--------------+-------------+-------------+
| [Submit] |
+------------------------------------------+
I'm open to any and all ideas, DB techniques, programming, or something else I haven't thought of.
Thanks in advance!
It's just a status of a record, an extra column in your tables holding the current status will be enough.