Hello everyone!
I am working today on a project to make an e-commerce website (Exercise given for my studies).
I am currently controlling the different entries that the administrator can make (Creation of a product, a brand etc)
To make my controls I use express-validator and here are my different tables with their parameters:
Customer:
User name
Email
Password
Product:
Product Name
Description
Price
Image URL
Quantity of product
Brand ID
Brand ID:
Brand Name
Logo URL
And more
I would like to know what is common to verify the validation of the data inserted from an e-commerce site.
For example for the user, I verify that when creating an account, the password, email, name is filled (.notEmpty())
I don't know if my question is appropriate but thank you in advance for any answers!
Have a nice day / evening.
So this answer may sound blatant to you and maybe nothing new. But you should validate everything that is coming from the client-side. You just can see what you're sending in your forms or when making a request. For the general guidelines, you can read: https://owasp.org/www-project-top-ten/
There are a lot of parts like not just security but reliability and such which could look like the same thing but are actually different and really depend on your business requirements and use cases. But I will write my own recommendations of what I observed through many years in web development, keep in mind that my statements are not the only truth or one way to do it or the best practice, so you should take it with a grain of salt, do you your own research and make some informed decisions.
Most basic things would be:
Sanitize and validate the data coming from the client-side.
Set predefined max length of some values if possible.
Check if an entity exists in a database, like username, product, or product quantity and such.
Always use the encryption for the passwords recommended at the current time.
Now more specific business and reliability parts could be (these are just recommendations):
Recommendations:
Username should contain letters and/or numbers only
Username, Email should not be case sensitive.
Disallow creating a customer with a very similar username like: John or J0hn.
Also one suggestion I would give is to look at some open source projects and how such things are done there, such projects are quite large so it will definitely take some of your time, but it may give you a better idea of how most of those e-commerce website work in general.
I really feel like this question and answer would fit better in softwareengineering.stackexchange.com. But anyway just trying to be helpful :)
Related
I am creating a CV website, but in difference to most I am trying to make it with database. I mean that usually such websites are static and all of the information is hard coded in the HTML. Since I am back-end developer I like to make it so everything including buttons and welcome messages are taken from the database. I am trying to store projects that I have worked on. There are several types:
Github Repository - a project that is done purely on github.
Work related - a project I have done on work and there is no github repository of it, only link to view the final result
UpWork or other freelance website - as a freelancer I have projects to fix something on a website and those projects can be viewed only on my profile there and I would like to list them with link to UpWork or wherever there is information on what exactly I was hired to do.
Now my question is - should I have different Entities and therefore different tables for these types of projects or should I have all of the possible properties in one table. For example if it is Github there is repository field and if it is work related then there is company field. If it is freelance it has link to the website I was hired on. Also there are different sub-types - web applications, desktop applications, games and so on.
As you can guess the changes are small (1 or 2 properties). I could very easily leave empty some properties and have another property projectType, but is this the right way? Should I have different tables and entities for them?
To give some info - I can work with both MySQL and NoSQL and I havent decided yet on which one should my website be made on. I am currently thinking about NoSQL. This means I am asking on how to store the projects on MySQL and NoSQL (by NoSQL I mean MongoDB). If it helps the languages I am choosing from are PHP (MySQL) and JavaScript (NoSQL)
I know that usually questions without code are downvoted, but this is more of a logic based problem as I know how to do it, but I don't know the best practices for my situation. This being said here is a small code for you -
console.log('Thank you in advance')
MongoDB lends itself very well to this exact situation.
You can create a collection where documents leave out certain fields if they are not needed for that type. The querying parameters of MongoDB allow you to check $exists on fields if you need to, and documents are stored efficiently, only taking up memory where a field is needed.
You can even setup a sparse index which is not required for every document. As long as your core document structure is the same, it is a good idea to keep them in one collection, and vary them based on their type.
I want to build a small Access database to better keep track of the companies we are looking at. I read Access 2010 Inside Out by Conrad/Viescas, did a lot of their examples and had the feeling I understood the basics, so I started with my own data base. Now the struggle begins, I think I have a basic misunderstanding here.
The relation I started with is quite simple: Each company we look at can have listed peers that we want to use to compare this company to. Of course, each company can have many peers and each peer can be the peer of many of our companies. So I modelled this relation as a many-to-many relationship:
Next, I created the form for a company, which looked something like this:
I related the subform I used to show the peers with a query that is based on tblPeersCompanies_1 and gives some additional information. What I now want from a user perspective is straightforward: A user should simply add peers to this subform for the company he is currently viewing. Access should then automatically update tblPeersCompanies_1 and tblPeers_1. The peers really serve no other purpose than to relate them to a company.
However, I struggle implementing this. Adding a new peer to the subform does not work, simply because it is not based on tblPeers_1 and if I enter the information there, Access notices that the peer is not in that table yet. (That is at least what I think the problem is). How can this be achieved though? I don't want the user to open another form, enter the peer first, go back to this form, type the peer again and the other related information. I hope that there must a simple way to do that automatically. Or is this indeed not so simple.
In summary, the question probably can be phrased as: "How to add records to a matching table and a related one-table on the fly in a form?"
Thanks to the great comment by #Remou, I found a solution to this problem. It contais three steps:
Use a combo box as outlined in another SO post
Use this function to automatically enter new records in case the peer is missing. Call this function in the "On Not in List" event
Show other values from tblPeers by linking it to the selected value in the combo box, as explained here
I have to say, this is much harder than I hoped it to be. Let's hope that the learning curve is steep and that it will at least be easy to use for the user and quite robust.
I have several different web applications with their own separate databases. All of these different web applications also use a common database for authentication which contains the list of all of my users and the user's name. To keep things simple, let just say my application databases are like a forum and they track user posts; in the tables they will store a userID and some post text.
Now the problem I am having is that some of my team members feel that what we are doing is messy and frictional because it kind of a pain how to get my applications to display a users name next to their posts which is a very common task. First I have to go to the application database and do something like SELECT userID, postText FROM tblPosts then I have to take that userID and go to the user database and get the actual name with SELECT name FROM tblUsers WHERE userID = X. And then merge data from those two queries together to get it out on the page.
I personally don't mind the way we are doing it as I think it's important to just use a single separate user database for data constancy, but some of my team members want to copy over all of the user names into the local application databases and store the user name next to the userID when recording posts so its super simple to get that information back out. In the event a user wants to change their name (a very infrequent event and we only have about 100 users) we should just run an update in the common database as well as all of the application databases.
This seems like a common issue people might have. Can someone please weigh in on the common approaches to dealing with the problem and what we might want to do.
You have a system with a working single-signon scheme (centralized user identity and authentication). That's a huge competitive advantage.
You've built it simply and cleanly. That's even more huge. This kind of thing is very hard to get right, and you have done that.
(If you were to try to build this with some system like LDAP or Active Directory, you'd have a lot of complex code to maintain.)
Don't let your fellow developers sacrifice that advantage for their personal convenience. If you have to synchronize changes to the user database, you will have problems when things get out of sync. It's a when question, not an if question.
By the way, if your user database and website specific databases are on the same MySQL server, you can do stuff like this to integrate the use of the two different databases. That may meet the needs of your developers.
SELECT u.username, d.opname
FROM userdatabase.users u
JOIN website.transaction d ON u.userid = d.userid
But if you do this, you'll make it hard to migrate your various website databases to other server machines in the future.
I've got several pages about products that I want to load into a database and instead of creating a separate html page for each product, I was thinking of creating a single page that will display whatever product the user clicks on. Each product page will have a similar structure with its name, picture, description, bullet points for features (varies from product to product), price.
My question is if I want to store all those information in a database (I imagine I would need a different field for each paragraph, picture, name, each bullet point, etc) is there a way to get around that? To store all those information in a single field or as few as possible and still keep the formatting. It seems like I would be overloaded with the number of fields I have to manage.
I'm starting to doubt if this was even a good idea to begin with...
Do not store all that information in a single field. If you are going to do that, then just create the HTML page and save yourself the trouble of having a database that you aren't properly utilizing.
What you need to do is identify the relationship between all parts of your page. For example, if a single product can have multiple photos you would want to define a multi table relationship that defines a one-to-many relationship between the Product and ProductImage tables.
Grasping how relational databases relate to the data you are working with can be difficult at first and it might pay off to hire someone for a few hours to go over what you are trying to do and how to implement this effectively using a DB. Since it is a real world example for you it will be an excellent way to learn. Good luck!
You're not the first person to want to do something like this. It's a very common problem that has a well established solution. You need to use what's called a web content management system. WCMSs allow you to use a common template throughout your website while filling in specific stuff for each page. I recommend Joomla because it's easy to setup, easy to use, and most web hosts support it. But you can also look at stuff like Wordpress or Drupal. Wordpress is more blog centric though and Drupal has a steep learning curve.
I'm currently at the very early design stage of building a web app that will be used by companies. Each company will have many departments and each department many staff. Each department will manage its own application with staff logging onto the application.
There is the possibility that staff across different organisations will have the same staff id. For that reason, I'm thinking of going with subdomains. Each company will have its own subdomain. I've googled a bit about using subdomains and have seen a number of positives, however not too many negatives except for the SEO implications (which do not interest me really.. this app will require direct contact with each organisation.. it's very specialised)
Can anybody think of any other disadvantages to going with subdomains? Can anyone think of a better way of doing things?
Regards,
Fiona
Your login information will presumably be in a database table somewhere. You will either need separate databases for each company and will need to identify which database to use. Or you will have all users in one table, with some sort of company id - and you will need to determine which company id to add to your login query.
You can make either of these determinations based on subdomain, or on a company-specific login page, or directory, or you can ask them to pick which company they want to log in to (which would be pretty ugly).
Subdomains should work fine. You'll have to do DNS setup every time you add a company, or work out some apache magic. You may need SSL certificates for each subdomain (I think - I'm not well versed on those). Other than that, I don't see any big disadvantages or advantages as far as code or architecture go. Marketing may have a stronger case for one over the other.
You'll still want to use other methods of making sure that users don't have access to other companies' data, especially if other subdomains are guessable.
We also have a multiple-company application, but decided to make all logins unique. This makes it a little easier for us to identify users uniquely at the expense of occasionally having to explain why some username is not available even though that user's company isn't using it.
using sub domains is a good idea, the only concern i have is regarding the authentication of the users. I am a .net guy so i am bringing up this query, i am not sure if you are using asp.net for your development. In case you are using asp.net for developing this website and you are using the asp.net membership, profiles and roles for authentication and authorization, you would end up having security problems. Because a user after logging into http://abc.site.com would have access to the site http://xyz.site.com also. This is the default way the asp.net membership thing works. So you would need to keep this in mind.
Rest i think the sub domain philosophy is good enough.
Subdomains might work just fine with asp.net membership. Because the was the tables are created for the membership provider there is a aspnet_applications table which has fields for te application name and description. In the aspnet_memberhip table, each user has a field for applicationID. If the application name is the subdomain then you could possibly limit which user can gain access to which application. XYZ subdomian would be one application with it's own ID, and ABC application would be another one.
Interesting domain problem. Good luck and share your results after it's creation.