I'm creating a token based rest api in php for e-commerce application.
Scenario :
Any visitor can add items to cart without logging in. These items are stored in the mysql database, cart table, with user_id value which defaults to 1. // As user is not logged in.
Problem :
After the user logs in, i am able to fetch the userid after decoding the token generated for the user, but want to know, how can i identify which items in cart table belongs to which user so as to update the actual userid against those products ?
Table :
customer_id int(11),
item_id int(11),
quantity int(11),
date_added datetime
Thanks in advance for any help!
You simply can't do it this way. You obviously a field in database which will be the same before, and after the user logs in. For exemple you could try to store an IP address or MAC address when user is not logged in. Then when user is logged in, you search for same values (on IP or Mac address) on the cart table, and set all the matching elements to the user ID.
In anycase, you'll obviously need to store something unique that will make a relation between then cart and the user.
Another solution, maybe the best corresponding to your needs, is to store the cart of unidentified users in cookies. Then, when users logs in, you'll have to browse all items stored in cookies to add them in your database with a correct user ID.
You should generate a (temporary) identification. I'd add an auto incremented column to your database id. After you have created the database you can retrieve the id with something like PDO mysqli_insert_id($conn). Store that id in a PHP session and you have it!
Related
I have a website where I store user info like user id, email , password, and some other info once user registered, where user Id is auto generated field in DB with Auto Increment method in MySQL.
Now I want to implement Facebook & Google Login. Facebook & Google gives very long user id(20 to 36 char long) once we make the request to there api but I can store max 6 char long user Id.
So I want to know what is the best way to store it. Shall I create a new table where I can create mapping with FB/G+ user id to my User's table user id and every time user login I check this mapping table and get user id created by my DB corresponding to FB/G+ user id and perform all the operation using my user Id OR shall I store FB/G+ user id directly to my User table but for this we need to change Table structure and many table because user id is FK for many tables
I am fairly new to PHP and am not sure how to do this.
I have two tables:
owner (ownerid(PK), username, password)
venue (venueid(PK), owenerid(FK), venuename, location, number)
owner stores the details of the current logged in user. Once the user is logged in they enter details into a form that gets inserted into venue table.
How do I take the ownerid of the current logged in user and insert it into ownerid (in venue table) so that at a later stage I can select all venues that a particular user has added, and only that logged in user can view them.
I am pretty new to PHP so would appreciate as much explanation / code as possible :)
Thanks!
If you have a logged in user you will be able to identify them either through a cookie or a session. If you store their ownerid in the session variable, then you will be able to access it whenever you require
$ownerid = $_SESSION['user']
You can then use that variable in association with the selected venues, and relate them together so only this user can view them when logged in, matching their ownerid
I am trying to understand the database design for an e-commerce site. I am having trouble understanding on what to do in the following situation. Say the user creates an account for the first time, and makes an order. I can write php code which will add the user_id (primary-key), first name & last name. But what if I want to add the user_id in the orders table (user_id in the orders tables is a foreign key). How do I get the value, as the user_id in the customers table is auto incrementing?
Are you using two tables one for storing user details and other for placing orders ?(which is better) If so my recommendation would be to use username (not first name or last name) as primary key and store the username as SESSION variable for each login and for each order add the username in order table along with orders details
There are couple of ways to do that, you can access the newly generated user_id by LAST_INSERT_ID() and use it in subsequent transaction, or you can store it in session and use it later when inserting in Orders table.
I'm confused on how to do this. Say the user creates an account with my ecommerce website, and then starts adding products into their basket. If I store the users username and password in a database table, and use sessions/cookies to manage the products in their shopping basket, what would I need to do in order to connect the users shopping basket to their account, so that when they log in they will be able to see the items they had previously stored?
Do I first allow the user to login, query whether they logged in successfully, and then make a session/cookie variable for their username? Or do I have to store the users cart items in a database and connect it with the user accounts table?
I'm confused with how to store a shopping baskets items into a table. Is that even the right way to do it?
There's no code yet, I want to create the databases correctly before I start coding and just need some advice. Thank you
If you have two tables, one for the users and one for the items, you can do something like the following.
Manage current basket items by adding to and removing the item_ids into a serialized array, which you can store in your users table AND the session at the same time, keeping them in sync. For example, if a user visits your store for the first time (not logged in, and empty shopping basket), you can create the session like so.
session_start();
We start the session.
if (isset($_SESSION['current_basket']) {
$current_basket = unserialize($_SESSION['current_basket']);
} else {
$current_basket = array();
}
Because this is the first time our visitor has visited our page, the session variable current_basket will not be set, meaning the above if statement will not run and instead just create an empty PHP array in a variable called current_basket.
Now, when the visitor adds an item to the basket, we just need the item's ID in your database and add it into the current_basket array.
$current_basket[] = $item_id;
Then we immediately update the session variable with the new array, serializing it in the process.
$_SESSION['current_basket'] = serialize($current_basket);
You now have a proper, usable array with all the product IDs for that person's shopping basket.
Now, let's pretend the user was logged in. We'd check for that and only add one more step.
$sql = "UPDATE users SET current_basket=" . serialize($current_basket) . " WHERE id=$user_id"
// Execute that query.
There, now that same array is in the database which you can then pull and set as a session variable when the user logs in.
You can run these series of steps everytime a product is added or deleted, keeping it updated both in the session and the database.
This is obvisouly a very watered down concept for the sake of explaining. Obviously, you'd need to manage the array better. For example, not adding a product to the basket if it's already there, removing items from the array...etc.
The key is to serialize the array, and store in the session always, and in the users table if the user is logged in.
Then when the user comes back and logs in, you can set the array in the session for them using the array in the database from when they were last on your site.
I would have the cart table cart_id / user_id / date_time_created then an item table indexed on the cart_id.
Also add a way to dump the cart_id and items out of the tables after so many hours or days otherwise your database will get huge.
And let your end users know that the items will be dumped after x amount of time.
I am currently setting up Open ID authentication in my website and I am having troubles incorporating it with my current Login System and database... I've read the article at Plaxo & it recommends this type of table to store the openid info...
create table user_openids (
openid_url varchar(255) not null,
primary key (openid_url),
user_id int not null,
index (user_id)
);
This is my current Users-info table
Userid(PRIMARY) | username(UNIQUE) | password | Email
Userid is used to reference user-details for comments, ratings etc. (So it goes into the comments table and the ratings table as a User identifier)
I want a system similar to what Stack overflow uses just login using your Open ID and it gives you an unknown(OPENID-provider) display name.... while keeping my current login system intact.
1) How can I add Open ID details of users to my current Users-Info Table without affecting the current login setup?
2) Currently I use User-id(generated unique for every user) to store in the session to maintain Login. What should I do now in case of Open ID?
*My Thoughts(I don't know if I am right or not)
- Add an open-id field to store the unique open id url provided by the open id provider for each user and set it to null for non-open-id-users.
- Make User-id a text field and store a md5 of the open id url.(store this in session to maintain Login).
- I have no idea how can I handle Display-name/Username which is set to unique for each user because I would like to show unknown(OPENID_provider) (for users using open-id) which can be changed from the profile settings...
Any suggestions would be helpful....Thanks
The idea with the table layout you show is to have a 1:many from users:openids.
Thus, no changes to the users table are needed.
When someone logs in with an OpenID, you check if that OpenID is in the openids table. If so, you have the user_id of the user and you are done.
Otherwise create a new user (with no username/password set) and insert an (openid,user_id) pair for them into the openids table.
You template can display whatever nice placeholder (such as their OP, or whatever) where it would normally display username for users whose username is blank.
Hopefully you already disallow logging in with blank passwords, so there should be no security issue there.
What about this?
Add a display_name column to the users table, which doesn't have to be unique.
Make username and password in users optional
When somebody registers with OpenID, create a row in users with empty username/password and display name set to "unkonwn (provider)".
Allow users to set username/password, if they want to switch to password-based login.
Allow users to manage their OpenIDs, so that existing users can switch to OpenID-based login.
This means that users can have username/password, but they don't have to. They also can have one or multiple OpenIDs, but they don't have to. They can use non-unique display name.
Option 1: Only one login type is allowed
Here's my suggestion (UPDATED to prevent the need to edit all business logic related to username):
Create a new column called loginid to allow the storage of OpenIDs and old usernames, Add the UNIQUE INDEX on this column as well.
Populate loginid with existing data from username
DELETE INDEX from username to allow them to be non-unique. When creating a new user from OpenID, set username value to unknown(google) as described.
Keep password for legacy logins, ignore it for OpenID.
Update only the AUTH portion of your code to look for loginid rather than username.
Option 2: Allow multiple logins (also easily extends to linking multiple profiles from various sources)
Create a new table to stand as a master user table and contain all required fields per user (maybe email from your example above).
Create a table to store authentication containing: userid (FK to master record), username (stores the username appropriate to the login scheme), password
There are obviously flaws with both of these options, but it will hopefully get you started in the right direction.