User id not set sometimes but fine sometimes too

I have forms where I use the registered user id and insert it again any other data that is entered by that user.

USERS_LISTINGS_INPUT_DATA_LogIn.php

I have used eCart to set session id = USER ID.

However when some users login in they enter data (i.e. a venue) and have their user id '80 or 800 etc' against the data with the insert and update date.

Other users login is and enter the same data and have a user id in the users table but that users id doesn't populate always in the following forms

So in a nutsell inserting the USER ID from the Session ID works sometimes but not other on the following pages:

90% of customers are fine, 10% of users have [null] in the DB for the User id next to their listing data, their meeting room data, their rates data and their spa data.

LISTINGS_Insert.php

MEETING_ROOMS_PER_LISTING_Insert.php

RATES_BEDROOMS_PER_LISTING_Insert.php

LEISURE_SPA_FITNESS_Insert.php

Can you see why from the code please?

Thanks,
Neil

If you can see that some of the users have a null in the db for the id it seems that this might be the problem. How do you have this column setup? It should be an auto incrementing primary key of the table with the not null attribute.

If the table is setup like this then there should never be a situation where the user can login but have no user id in the session. Make these updates to your db then try updating the records for the users that have a null value now. Once you update those users do some testing to see if the problem occurs again. Let us know if you have any questions or problems.

Eric, hi thanks for your help.
Sorry for my late reply I have been super busy.
I am not sure I have explained this problem or I don't understand your response.

I have a USER table with

Primary key, user id not null
First Name
Last Name
Company

The I have another table eg orders:

Primary key, order id not null
Order name
Order detail
ID of the user = user session id (which matches User id above)

Sometimes the ID of the user in the order table is null
Therefore sometimes the session id is not recorded and inserted into the order table for some users. So for some users this is a problem and for some users the User id/session id is recorded properly in the order table.

SO I have user 1 with all the details in user table.
But in the order table where is should be eg. Order id 5, name, detail, user/ession id 1 it is eg. Order id 5, name, detail, user/ession id null.

How can this happen for some and not others.

Is this a cookies issue please?

It is possible that there is some cookies issue, to determine why this is happening for some users and not others though you would need to be able to reproduce the issue first.

Are you using a cookies based cart or the regular session based cart? At what point do you set the userID in a session variable? Is it possible that the user making the purchase has not triggered this code that sets the session variable for their id? Also do you use this user id session variable for anything else in your site, if so do you have any problems with any of the other functionality?

Eric,

I tested this with complete private borwsing so no data is accepted by the browser - no cookies and I reproduced the problem.

So following on from this I have the following problem:

1. How to enable cookies for the user or
2. How to not allow the user to login if cookies are disabled and redirect (would not prefer this option).
3. How to override their cookies selection/or not be reliant on cookies.

I also have two other problems which I would appreciate your help with.

A. Disable the back button because I think the back button is also clearing the session.
Can I stop the usage of the back button clearing the session?
Most scripts suggested are rubbish

B. Double click on add/update causes two records to be added or a problem with update.
How do I stop this from your point of view. Again most scripts suggested by users in this forum have not done the job.

Many thanks,
Neil

I think it would be best to move away from cookies and keep all of this server side. The best replacement for the cookies is using session variables to hold the details of the user. When the user logs in you should store their userID in a session variable then use this variable wherever you need the id of the user.

If clicking on the back button is clearing the session then there is a problem with session management. A session variable should remain intact throughout the life of the session, either until it expires or the user closes their browser. If you are having the session cleared when going from page to page then this is a major problem.

To check on the settings for your session you can create a phpinfo page. To make this page just create a new php page with this line of code in it:

<?php phpinfo(); ?>

When you view this page look for these settings:

session.save_handler should be set to: files
session.save_path should be set to a folder on the server that you have access to
session.use_only_cookies this should be set to Off

As a test of this try using the following two page test attached to this post. You should go to the session_test.php page first and see the session information there. Then click on the link to the other test page, it should display the same session information for you there. If it does not then there is problem with the session that needs to be addressed. Post back and let us know what you discover.

Eric,

Thank you for your suggestions and test files.
These test files worked for me.
The session with my normal settings are fine.

However I agree with your comments "it would be best to move away from cookies and keep all of this server side. The best replacement for the cookies is using session variables to hold the details of the user. When the user logs in you should store their userID in a session variable then use this variable wherever you need the id of the user."

I would like to switch to session variables to store the user id where I need to insert it.
However I don't know how to do this.

I thought it would be useful to email you a version of my database, and my files so you can see the existing code (total 3.9mb) and suggest how I might switch to storage of the USER_ID over from session to server variable, to then insert it in various tables as I wish.

I have included a view files so you can get a good idea of the data interaction, between user, main listing and special offers. partial DB attached.

Many thanks,
Neil

Thank you for the files, this clears things up a bit. Here is how I see things.

Currently you are having users login with the USERS_LISTINGS_INPUT_DATA_LogIn.php page. In this authenticate user server behavior you are storing the userID in a session variable called USER_ID. This is the session variable you should use to insert the record.

Rite now on the listing insert page you are setting the same session variable to itself but only if it is not set. This means that if the user is not logged in when they get to this page the USER_ID session variable will always be blank.

To resolve this you need to add restriction to the listing insert page to force users to login before they can insert a listing. This will ensure that the USER_ID session variable is set when they are on this page, and if not they will be redirected to the login page.

Eric,

Because the users see one menu before they login and one menu afterwards they cannot add/update a main listing before they login because they don't know the insert or update link unless they copy it after they login of course.

I think the session variable is not being set due to cookies being blocked on some machines? Do you agree?
If so we are back to your server variable suggestion which I don't know how to implement and change all my pages?

Thanks,
Neil

I don't think this is the case, the session information is stored server side, not client side if you have the settings like I mentioned in post #6. If you put the access rule on the page to only allow logged in user's it would prevent this from occurring regardless. If for any reason the USER_ID session variable were not present the rule would not allow them to insert a record.