I have a new website that does the following for account creation:
First, it checks in the users table of the Users db if there is an account with that name
Next, it INSERTs name into the users table
Finally, using a different account, it creates a table named after the user, using a statement like: CREATE TABLE $name LIKE template
However, this creates some issues. Occasionally, table creation fails, so I have a "ghost user" that lacks a table. Ideally, I would have the account which accesses the User database be separate from the one which accesses the other db with all the tables.
How could I do this? Could I have one account with permission ONLY to run stored procedures in both DBs? If I did the last option, how could I guarantee completion of both tasks? This is using PHP.
Edit: Thanks for the help in the comments! If someone could summarize the lessons learned & answer this, I will accept your answer. I've taken the advice and completed the change in about 2 hours.
Related
I have a site which has two types of users that are stored in two different tables one is saved as a user and the other one as a business in the user table its columns are as follow:
first_name, last_name, user_email,user_pws
And the business columns is as follow:
business_name, business_email,business_pws
I want to make a PHP coded login page that if the user enters email and password the login system will check which one the user is. how can I do this? my current code is a simple login form.
MAY LEAD TO SECURITY RISKS
this was just for what the user here was asking
It's a little weird because you have to make sure that emails are unique keys however making them a unique key in each table would still mean someone could make one in each table. I'm not sure if that's what you're getting at and I guess to counteract that you could have a table of used emails....
But to get to your question, IF the emails do not overlap between tables I imagine some SQL statement such as:
select users.user_email, business.business_email from users,business where users.user_email='foo' or business.business_email='foo';. I'm not too great with SQL yet either but you can mess around with something like this and I'm sure it'll get you on the right track.
I'm developing a web page where students, after registering, can introduce their school schedule, mark test and calculate averages. My problem is:
how do I do for each user to have their own schedule, calendar etc. I could be simple for you but I'm having difficulties solving this.
This is how I want schedules menu to look
all the data introduced for the schedule will show up on the table
You have to look at how a relational database works.
Everything you're trying to do is use a foreign key.
IMHO best way to achieve this is to register user ID+name in $_SESSION then, when he reaches the page, retrieve schedule from where it's stored. Depends also on the schedule/calendar format
I'm currently working on a website which will have many users on it. These users are stored in a table with each having a unique id. The website will contain projects that the users can complete and these projects are stored in a separate table with unique id's as well.
I need to make the users have a page they can view which will display a list of all the projects they are currently working on.
To do this, I am going to set up another table in which each row will have the user's id as well as the project's id that they are working on. All of that will work alright but I would like to allow users to cancel their projects if they please. I am aware of how to do this, but I have read that deleting rows directly from a php script is insecure so the user used to access the database from PHP does not have 'DELETE' permissions. I am wondering if I should just delete rows at will when a user specifies which project to delete or if I should just have another field and simply mark each user-project row as being 'cancelled' in another field so I can work with them myself.
What you should do is, for maximum security is, have a parameter in the database table called "isActive", or something of that nature, that is a BIT data type to represent a boolean. If that boolean is false, then do not delete the project from the database, simply hide that tables data (do not display it on the site, but keep the data stored in the databse). That way, not only is your database secure from malicious users who would like to destroy data, but projects can also be "re-instated" if they wish to re-instate it. If the project sits around for a certain period of time, say, 14 days, just have the server delete it, not the user, if you wish. This worked for me in the past.
Hope This Helps!
The most common approach to this problem is to have a field in the table that can be used to mark a record as deleted. This would be the only access the general user would have to the table as far as deletion goes. Some people also have a full delete, which states clearly that it will never be accessible again after the operation is completed.
Personally, I prefer to retain full delete permission to administrators allow the user to only mark records as deleted. If you're concerned about space, add a last accessed field as well, and schedule at set intervals a call to perform a full delete on any records that are marked as deleted and have not been active for a certain amount of time.
I currently maintain a DB table of users, when after logging in I update the table with their ID and login_time. This works to a point but currently I can't tell if the user has been active since the login or for how long.
Is there a better way to get a complete list of users that have been active in the past X minutes?
The best way to get what you need would be a "Last Activity" column in the users table. You would just update it whenever a user access a page. Depending on what information you need it could replace the login_time column or it could be a new column.
You'll have to keep track of when the user made their last request in your database as a separate table or column. You can then formulate a query to select, e.g. all users that have made a request in the last 5 minutes.
PHP itself does not store - or care for - that kind of information. Unless you happen to have your own session management module which does store this kind of information, then you could use data from that.
I want to notify users of changes on a site. Users are subscribed to different kinds of changes so I don't send all changes to all users.
Here's what I am thinking: at t=0 (i.e. an if statement that checks that some table is empty) I basically have an SQL query that fetches the appropriate changes and mails to the appropriate users. I then populate a user_changes table which essentially stores what changes have been mailed to what users. Mailing is done with the php mail function
Then at t>0, I run the SQL query again but this time with the condition that changes+user are not in the user_changes table. The main issue i see with this is that the user_changes table could get large very quickly. Is this a problem? I am trying to avoid hacks that use dates to filter stuff, since I want new users to be able to receive old changes that are relevant to them.
Appreciate suggestions.
How about having one entry per user, and a record of the last sequence number of updates? when you send the email updates, update the record with the latest and greatest. Your table should be sized with your user base, then.