I have to build a web app with the following db structure:
I have the structure as in the sketch.I have to separate
the people to person and to user because of there are people who
will never have user account and just simple added by administrator
to the site db.
There is an application form to register to the site.
There must be fill the person fields and the user fields
If the admin adds the person to the db(without user info),and this person wants to register later by him/herself how to deal with this case?
He/She tries to register but filling the Person fields will duplicate the data. In this case Person fields already exist.
Do you have any idea?
Update1:
Thank you for your answers i already known that how to store the data fields in the tables.But don't know how to deal the case when the admin register the person data and that person comes to register him/herself
PS:forgive me but i don't have a modeller tool now.
Is important to notice that meanwhile a Person can be or not a User, a User can be also not a Person. (For example, user roles that will deal with automatic maintenance of the database)
Everything is about how your business model is structured.
Leave User as lightweight as possible by putting all data about persons in Person. (name, dataofbirth, email, etc.)
In User just add a Foreign Key nullable into Person table records and only add data about a user in this table (id, password, lastlogin, etc..).
When the form is filled by the user, first add a record in Person and if data corresponding to User is filled, then grab the id of the Person you just added and use it as the data to fill the Foreign Key in User.
If the Person data is already on db, just notify the user and ask him about using that old data or update it... always taking into account security and privacy issues. (This user may not be who he is claiming to be.. maybe you should ask him to confirm his email as many newsletter do)
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 using Laravel for a little app. In this app I added the auth things of Laravel (verison 5.3), so I automatically got a possibility to register and log in.
So what I got now are a few controllers, 2 vies and a table users, with name, email and password and a unique auto incrementing primary key. What I want now, is to make the logged in user able to add additional information, like City, Street, Telephone, etc..
I don't want to make the user able to add this directly at register. What I want instead, is, that if the user is logged in, he can navigate to a view (lets say its reachable through the route /changeUserData. There, he can find a form. In this form, initally there is no data, he can enter everything (as I said, like City, Street, etc.) and save information. I'd like to save this information in another table in the db, called user_infos, with several columns containing City, Street, Telephone, etc. I'd like to be able to have this second table without a primary key, but with a foreign key - the primary key of the users table.
So the process would be, navigates to the view with the form /changeUserData. Then there is a lookup in the table user_infos, if the logged in user already saved information there. Therefore, I'd need to look up the primary key of the user via the email-adress (unique as well), which is stored in {{auth::user()->email}}. If he didn't save any information there yet, then he gets a blank form, where he can enter everything. Clicking on save, makes a new entry in the user_infos table, containing all information entered, as well as the foreign key got from the users table. If there is already an entry for the user, the information should be already shown in the form inputs, and the user should also be able to edit the information and save the updated information.
I know this was much text. Basically what I need to know is how to really do the database things. So how can I lookup the primary key (respectively the column with the name id) with the email-adress. How can I then create a new row in the other table, containing this id and the information entered? And how can I get the information from the database then to add in to the form inputs? Basically what I found is Eloquent ORM, but I doesn't seem to understand it. Can anybody give me an example of how I can do this?
Please note, that I'm completely new to Laravel, as well as this hole Object - Model thing, this might be the reason, why I'm confused about it.
Have a look at this series https://laracasts.com/series/laravel-5-fundamentals
The Eloquent tutorial: https://laracasts.com/series/laravel-5-fundamentals/episodes/8
The directory structure will probably be a little bit different as it is a slightly older version of Laravel but it will get you started.
Hope this helps!
I create an application that will show users registered in the system on a map. But I need to adhere to some kind of security:
I want to store the user information (name, address etc)
I create a UUID for each user
This UUID is the only reference being
displayed on the map, so the user of the map cannot see the clear
names
the UUID is connected with a user directly and only with
this user.
I dont'see at the moment how to solve the issue, that a user registers in my database and gets a UUID assigned, but it should not be traceable at the end, which UUID is connected with which user. I hope my problem came across.
In terms of privacy issues, I should not be able to see clear names in a database for each user so data privacy is ensured and only UUIDs are a reference. How can I solve this?
I'm not a 100% sure of why and what you'd want to achieve but it seems like you have 2 options:
Encryption - if you're afraid someone will get sensitive data from your database, consider encryption. When it comes to UUID you are always going to be needing some sort of way to identify a user so the only way to protect your data is encryption.
If you're afraid someone else from your team (who has direct access to the database) may take advantage of the sensitive information (like get the address of a user) you could create a separate pivot table which correlates between the user data and the uuid i.e user_uuid and this table will contain user_id,user_uuid (the first one is numeric index, the second one is the uuid). Then you could create access control rules on the database itself and only you will be able to access the main user table, everyone else won't.
Hope this helps.
I am developing a web-based iPhone app and possibly a PC friendly website version as well. The goal here to to allow users to submit a form where specific input values would be stored into a table in the database.
Mind you this information is being gathered for public display and will be posted onto a calendar or list.
However, to prevent from any trolling or spamming, I'd like to make it where submissions have to be approved prior to being submitted into the table.
I have no problem with creating the table, connecting to the database, storing input values into the corresponding table columns. The only issue is how would I go about setting up an approval system? Can I add information to a table via email? Is there a way to approve admissions in cPanel?
This is something that I would like make as smooth as possible, I am expecting a lot of submissions daily with quite a bit of information.
You can have two approaches for this.
Approach 1
Have two copies of the table (which you want to save information
into). The first one should be named tableName_Input. The second one
should be tableName_Final.
Any Data in '_input' is considered raw and needs approval. Once approved the data will be moved into '_final'. The LIVE list/calendar always read from '_final' data.
Approach 2
Have a column named 'isApproved' with a flag 0/1. If 1 it is approved, else it is not. Only show data that is Approved.
Now, how do you get the data approved ?
You have a hard fast rule like spam filter that tells certain post is valid and approved by default
After every post, you send the user an email or some notification (unique to the user - post) that when answered back, shall mark it as approved.
Optional: You can place a column called as 'approval comments' to fill in something at the time of approval.
Flow chart
Tables
'FirstSubmitContent' - Table to store user submitted information
prior to approval.
'FinalSubmitContent' - Table that stores the final information
Code Pages
Content Page --> Contains the form the user fills the content
ContentActionPage --> Calls the controller --> calls the Model
Controller --> calls the model based on page action
Model --> Interacts with the Database table
I do not have any tools at my disposable now to write more detailed Code or Flowchart. I hope this puts in the right direction.
Validate the form on submission and save info in a temporary table in your DB with a randomly assigned activation code (you could use sha1). Then send an email to user with activation code and a link to verify it, ie. domain.com/activate.php?code=abcde12345.
The activation page can be very simple with just a $_GET['code']. Then check if you find a match in the DB for that code and finally prepare your query with all the info you gathered before to store it permanently.
Then you can make a cron job to delete all records from that table every 24-48 hours so users will have to activate within that time range.
I am building a system that will use a commenting based ticket system. I would like to get some opinions around the idea of flagging a user as deleted or removing the record completely.
Ideally I want to keep the system free of old accounts but at the same time by deleting a user the commenting within the ticket system may not make sense.
Has anyone come up with a solution to this type of problem. My ideas so far:
Delete the users account, comments and all other relevant data.
Flag the user as deleted and create a brand new account if they subscribe again.
Flag the user as deleted but if the user was to try to subscribe again update and unflag as deleted instead of adding a new one.
Delete the user account only. Then when fetching comments etc. check for an associated id, if no result found then display the comment with a message "the users account has been deleted".
What do you think?
I would say that the third option is the best choice
My reasoning for this is any tickets stored in the database should be kept for the life of the database, if you attempt to delete a user from the database, you will remove that users reference to any tickets in the database.
(Thats if the database will let you delete it since the user's id will be linked to any tickets he/she may have created)
When that user goes to create a new account in the ticketing system, the tickets that he may have created months ago have dissapeared and may now have been created by null.
I would always use the last solution: delete the user account only and show an "account deleted" message if the poster's account doesn't exist anymore. If you don't allow users to change their username, you can also save the poster's username (beyond his ID) and display it as plain text if the user deleted his/her account, or as a link if the user is still active.
If you're representing the user <-> comment relationship with a FOREIGN KEY, you can't delete the user without deleting the comment or updating the comment's associated user to either NULL or to point to some "deleted user" fake user account (in either case, losing the information about the user who posted the comment).
The ticketing system I wrote basically did number 3. Anything else will ruin any audit trails you need to keep.
If you need to get rid of old stuff one way is to set cleardown of old tickets. Then, when all related tickets for an account are gone, you can remove the account.
It really depends on you use case.
Personally I would never delete stuff like user-accounts from a db completely.
So option 1 is out. (but that's just me)
Option 2 has the problem, that you'll have lots of dangling user-accounts.
Option 3 looks like the best option -cough- audit trail -cough-
Option 4 is asking for trouble, you have a link to another table, but that data has been deleted.