I'm now learning about server-side tracking (as opposed to client-side), and I can't understand how the identifying of a unique user is done, when we use server-side method?
What I find on the internet, is only this phrase "unique id is generated and then mapped against a user every time they take actions". But I don't understand what originally allows to create this "unique id" in such a way that it is unique for every unique user.
Could you please share this in some broad terms - without a specific code, just the working principles and mechanics?
Thank you!
Related
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 :)
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 need to set up user permissions within the same table, based on the value of a field. I know that this is not directly possible in Access but a post on Allenbrown.com points to a way of doing this see here. I'm not proficient in coding so I'm hoping that I can get some directions from you. Here are the details:
I have two tables in the database, a parent one populated via a form and a children one populated via a subform. The parent contains companies and the child contain subsidiaries of those companies. In the child table, I have a field called "Domicile" and I want to discriminate user access based on that. Because the database will be used by a variety of people worldwide, my plan is to create user groups based on location and allow users to edit (or add) information based on a match between their location (as specified in the group) and the domicile of the subsidiary. For example, a person in Europe will only be allowed to edit data for subsidiaries that are in Europe, even though companies from other domiciles may be stored in the same table.
I'm looking for some guidance here as well as suggestions as to how you think may be done most effectively. I'm not partial to this method, that's just something I came up with to put some logic behind what I'm doing.
Thank you so much!
The important thing to note in Allen's description is (emphasis mine):
Assuming all updates are performed through forms, the Current event of the form then locks the fields based on this property.
There would be no practical, bulletproof way to prevent users from viewing and altering any data in the table(s) if they open the back-end database file directly.
Since you are asking for advice on how "[row- or column-level restrictions] may be done most effectively" the first issue you need to address is how "effective" those restrictions really need to be:
If you can accept that these will be "soft restrictions" (really a matter of convenience to the user so they don't accidentally alter certain records or fields while using the forms), then Allen's approach might be sufficient. (If so, then follow Allen's instructions as best you can and ask new question if you need help with a specific aspect of that implementation.)
On the other hand, if you need "hard restrictions" (serious protection against mischievous or malevolent user activity) then you'll have to employ a different database back-end -- something like Microsoft SQL Server -- with a richer set of security tools for you to use.
I have a web application that uses a relational database (MySQL). We're adding a new feature that will allow certain users to dynamically construct 'forms' from a pool of optional form elements and distribute these forms for completion/submission to other users.
The problem lies in storing the completed form submissions. Each form can and will vary in the number and combination of form elements, and with a relational database my options are somewhat limited to dynamically creating a new table to hold the submissions of each form (seems like a bad path to go down) or storing each of the submitted forms as JSON in a TEXT column (losing all useful querying abilities of RDBMSs)
I've never actually used MongoDB in a production project before, but I'm thinking it might be a good idea to use my MySQL relational database to store all the forms created by certain users of my application, and then store all the submissions in MongoDB with each document referencing the UUID of the form in MySQL.
The first disadvantage I can think of with this approach is there's no referential integrity between form submissions and the forms located in MySQL. If I delete a form in MySQL, all of the form submissions will have to be manually deleted (if I want to replicate the 'Cascade' effect)
Would I store all of my form submissions for all of my forms in a single MongoDB collection as individual documents? Any advice is greatly appreciated. :)
EDIT 1
Based on the documentation here: http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections
I'm now considering creating a new collection to hold all the submissions from each unique form type.
EDIT 2
After some careful consideration and the advice of others I've decided to abandon my dual-database approach to solving this problem in favor of a relational-database schema that I think solves the problem of creating dynamic forms and saving the form submissions in such a way that they're easily query-able for complex reporting.
Essentially every record in 'forms' represents a unique form that was built by a user. 'forms_fields' has a foreign key that references the form and an enum-type with the options:
1. checkbox
2. textfield
3. textarea
4. select
5. multi-select
6. date
'forms_fields_options' contains all of the 'options' a select field would have.
With these three tables, users can create customized forms.
When another user fills out & submits the form, a record is created in forms_submissions. For each field, a corresponding record will be created in 'forms_submissions_fields' that references the form submission and the forms_fields_id. The final table, 'forms_submissions_options_multiselect' is essentially a join-table to indicate which options from a multi-select form field the user selected.
A colleague of mine recently lead a webinar on just this subject, titled "Hybrid Applications with MongoDB and RDBMS". You can view it here:
http://www.10gen.com/events/hybrid-applications
From the comments, it looks as though you have already decided to go the RDBMS route, but hopefully this can give you some ideas for a future project, or be beneficial to someone else reading this thread.
Good luck with your application!
This can definitely be done in SQL using EAV. So NoSQL is definitely not required.
Using a tool like MongoDB could be a good fit for the flexible results you want to save, however, there are some trade-offs here, but they may not be exactly what you're expecting.
... storing each of the submitted forms as JSON in a TEXT column (losing all useful querying abilities of RDBMSs)
How many form submissions are you planning to have? What type of querying are you planning to do?
My experience with MongoDB is that it performs very poorly when you're querying against data that is not indexed. In addition, aggregation is generally done in batches using Map/Reduce (or the new Aggregation Framework).
If you compare the complexity of doing roll-ups or the efficiency of doing queries, it's not clear that MongoDB is significantly better here than EAV.
If I delete a form in MySQL, all of the form submissions will have to be manually deleted
Oddly, I have rarely seen this as a problem as you will probably never delete the form in SQL. you will likely do a logical delete and never really remove anything. So this is probably a moot point.
Would I store all of my form submissions for all of my forms in a single MongoDB collection as individual documents?
Again depends on how many forms and submissions you're planning to get. If you have lots of both, then using a collection / submission is going to be very difficult to shard later on.
Honestly, I would use a single collection and then override the _id field to something that can reasonably be used as a shard key. There are some fancy tricks you can play here, but that's beyond the scope of this little write-up.
Summary
End of the day, you can definitely use MongoDB for this problem, but it's not a "home run". If you are unfamiliar with MongoDB, this is definitely a fair "learning project", but expect to hit some roadblocks around querying and aggregation.
I think you're overlooking the fact that an RDBMS will allow things like EAV (Entity-Attribute-Value, which is horrid if you overuse it, but can be great in moderation) or join tables, to construct multiple ordered relations from a single form to various form elements.
I'm not suggesting that an RDBMS is perfect for everything, or even your situation, but I know I have had to build similar systems and have never had to go noSQL to support them in a reasonable way.
Edit: More to the point... storing actual field values puts you one more relation out from the original form elements, but if your UI keeps things consistent you can do this generically. I'd say looking further into which noSQL solutions allow the particular kinds of value-based querying you need might shed more light on your options.
We're developing a system to replace an old application from our clients.
Actually there are many entities (like merchants, salesmen, products, etc) that must have a manual assigned ID -so they can be integrated with other existing systems. i.e. accounting.
We think the best solution is simply allow the user to assign the entities IDs manually when the entity is being created; we're going to suggest him the next available ID, and the user will be able to change it if they want. no updates allowed! (muahahaha)
We'll be glad to hear your thoughts about. Pros / Cons
Thanks in advance :)
PD: Do you know any documentation about? -Entities and IDs-
UPDATES
We think there should be cases when this applies and do not. so...
Additionally there are cases when the client literally wants that a given entity has an Id they bring. organization internal codes I think.
Never, ever, ever let the user have access to assign or create the underlying objects identifier. These must be system maintained.
Imagine the nightmare of trying to figure out which entity a related entity actually goes with in the event that the user picks an id that is already in use.
Instead, you should have a regular entity ID of some type (int, guid, whatever) that the system assigns and uses for links to all dependent objects. Then have an "external" id of some sort that the user can put their own identifier in.
Maybe that relates to an external system in some way, maybe not. Point is, you'll be able to maintain your own consistency regardless of what they do.
What is usually done is to specify your own, usually hidden, identifier that is used internally. Then create a second identifier that the user can use as a separate data field. Also, you can get into a bit of a concurrency trouble if you try to suggest the next ID.
I guess this boils down to a separation of concern issues. If you've been developing apps for more than a year you should already know why you need an object identifier in your rdb's, if your users need to concern themselves with assigning and/or managing your underlying object identifiers then you have a design problem, and this problem is that you are mixing data access/storage concerns with business logic. As others already said the best approach is to have two identifiers, one that is transparent to the user and used internally in your app and the other to be used in your integration processes.
I've seen a similar case while working with retailers, there's an id and a product's SKU, the sku itself could be the id yet to allow for a good design we have both.