I reckon every page that has a form will need a unique ID generated. How would one go about storing, retrieving, and verifying this ID in an online environment?
Would you create a new database and run an INSERT query on every page that has a form on it? Followed up by a SELECT query on the forms target page to verify?
Would you then need to manually run a script that checks for old IDs to delete them? Or is there a more efficient method to all of this?
Edit: This is to prevent a script that executes a major action with a relatively simply query from being abused. Say limited_event.php can be POSTed to with a createNewReservationAutomatically variable that does just that, creating a temporary reservation with whatever contact details were submitted for manual verification later.
If the script is requested repeatedly with those variables, it will eventually fill up all available spots (and generally flood your database).
From my understanding referring URIs can be spoofed and are thus unreliable. What's a web developer to do? You have my upvote if you don't say recaptcha.
You seem to be asking 3 questions: how to prevent duplicate submissions, how to "reserve" spots, and how to protect a form from malicious input.
To prevent duplicate form submission, use http://en.wikipedia.org/wiki/Post/Redirect/Get
For reservations, see https://stackoverflow.com/questions/tagged/reservation?sort=votes
To protect forms from malicious input you need to do server-side validation, use XSS, CSRF and brute force countermeasures
Related
I have an Access 2013 DB with 2 subforms: The first one provides current data and the second one I'm trying to set up as a sandbox space for users to make changes and updates at their leisure. When they are ready to submit those changes and updates they can hit submit and their results will update the current data and table info behind it.
Been a while since I've messed with Access so I can't recall if this can be done so thought I would ask.
It can’t be done without a rather messy approach. Forms in access ALWAYS edit ONE row.
What I do in these cases is allow the user to “edit” as much as they please.
However, say we are doing a “classic” check or donation amount enter. So you have a donation amount (say $50), but you THEN have to distributed the amounts to various donation accounts.
With the above, you don’t want to save the data until such time that the amounts distributed to accounts match the donation amount.
Because we can’t contain the form + sub form as a “single” update, then what I do is add a posting flag to the parent form (the one record in the main form).
The user can then edit/add, go away for coffee, and come back and edit some more. You can even come back the next day and continue editing.
Once the user is happy, then you have a post button on the form.
If the user hits post, and the balance amounts don’t match, then you don’t set the postOK flag = true.
The above will thus NOT provide a means for the user to bail out, or un-do their edits to the “whole thing”, but it does allow you to determine that the data entered has been “balanced” and verified. And if the “balance” did not occur, then you can skip that record, or introduce a process in which the data is not posted or marked as done until such time that the data balances.
Here is a screen shot in Access of a “classic” money distribution to several accounts. You can see the donation amount on the left side, and on the right side is the account distribution of that amount.
However, at the bottom of the screen, for the “job task” the user is working on also has a post button. When they hit the post button, if the amounts don’t balance out, then the posting is NOT yet done. In fact, I let the user enter "many" donations, and then they can "post" all at once for ease and speed of working. The "post" does NOT actually post, but checks the balance. So users "think" they are posting, but it only really ever sets one value (a flag POSTOK).
So to run a report, it can’t be run until such time that the post button was hit.
As noted, this approach will NOT give you a “bail out” option to exit your data entry, nor does it allow you to “undo” the data entry, but it DOES allow you to verify the posting is “ok”, and “valid”. In many cases this approach will suffice.
However, if you looking for some kind of “undo” for the form + sub form edit, then Access quite much is not the correct tool for that type of business model and edit.
I would suggest you set up a local temp table for the sandbox.
Then when you say 'When they are ready to submit those changes and updates they can hit submit and their results will update the current data and table info behind it.' ….. instead what happens is the Sandbox Temp table record appends or inserts/updates the actual table.
If this is a split multi user app and the Sandbox temp table is local - then the data is indeed temporary and the update must occur within the user's session. But the overall design is quite simple.
After finally getting back into this I realized I was looking at Access development through the eyes of how I would do it in Excel; both different ecosystems. I took off my Excel forms dev lens and a few things occurred to me that I think may help others with similar struggles:
Access and Excel are different VBA development ecosystems. You can’t necessarily code it in Excel and expect it to work flawlessly in Access.
A subform is just a form...and like all forms its controls, code, and behavior don’t change in functionality but in presentation based on form type (datasheet, continuous, etc).
Treat each Form and event code independently of each other. If your subform on a parent requires events to kick off when a user adds, updates, deletes, validates, etc. that code should belong in the form that makes up the subform.....not the parent.
The parent form should only control filtering and results from the subform as well as it’s own set of actions the user has.
The Screen method is amazing and one I think would have saved my life for tracking changes. Great link here: https://www.datawright.com.au/access_resources/tracking_data_changes_in_access.htm
This should be a pretty common issue: let's say I'm updating a users table as well as a users_organizations table. From the UI perspective, there is only one button "Save".
I can either:
1) Create a single API route
2) Create one API route for each resource (one for users, one for users_organizations)
And then, suppose I choose 1). Should I update both tables in a single database call or should I split it up into 2 database calls?
In general I'm never sure how to approach these problems. Sometimes there's an action that affects more than 2 database tables at once. How do I ensure robustness, proper error handling, and keep my code sane all at once?
Definitely a problem I struggle with as well.
From what I've seen in the past, most operations that go along with a UI action are related, and can be given a common action name like update-user when clicking "Save". I'd have a single API endpoint to update the user, such as PUT /api/users/123 in a REST API. The body of that request would contain updated fields and new organizations the user belongs to.
Then on the server side I would make 2 database calls, one to update the user table and one to update the user_organization table.
If you feel 2 operations are so different that it's difficult to come up with a common API endpoint name, or if they need to be called independently in other parts of the app, I would argue that they should be 2 different API endpoints.
At the end of the day I try to ask, if a new developer were to try to understand this code, what would be the simplest approach?
What is the best practice both security and performance focused to avoid letting users see incrementally IDed data in database or other dataset.
Main concern is to avoid urls such as
www.myweb.com/user/123
This of course applies to posts, users, files or messages.
Implement permissions so that only authorised people can see/change/delete data.
If you still want to hide the incremental ID from users or API consumers, you could add a hash column to your database and index it, then expose that instead of the incremental ID.
Hiding Incremental IDs
Depending on your programming language, the unique ID you assign your users may not need to be displayed in the URL. For example, with PHP, you can use the $_SESSION[] array to store values on your server for each user. Those variables will never be seen by the user, but the server will be able to identify each user appropriately (via PHP cookies) and serve them the correct page dynamically.
For example, when a user signs in to your site, after authenticating, your script might do something like:
$sql = 'SELECT id FROM user_table WHERE name = :username';
// Prepare & execute SQL query, putting result in $sqlResult
$_SESSION['user_id'] = $sqlResult;
Now, whenever the user wants to visit their own page, your server will know which information to fill your home page template with -- and the URL will appear the same to every user.
If a user wants to visit another user's page, you could do something similar: upon choosing a specific user page to visit, your script could set a $_SESSION['visit_user'] variable. Thus, you would be able to fill a visit page template with the appropriate information, and your user will be none the wiser.
This same tactic can be applied to posts, files, etc. that are assigned incremental IDs.
But Is This Necessary?
As you yourself mentioned in your previous post, there are plenty of examples of sites that use incremental IDs -- and with no qualms about displaying them. Because while this does give a malicious user the ability to view other users' IDs, etc., this doesn't necessarily pose a threat to your site's security. If you follow basic security principles (require strong passwords, watch your MySQL users' and files' permissions, sanitize user input, etc.), it doesn't matter if malicious users can guess at auto_incremented IDs. Those IDs aren't valuable information unless your site can be exploited in another manner.
I'm hoping this isn't harder than it seems.
I want to create an HTML form with a few text boxes that will allow people to enter in some data and I want these changes to be saved to the form.
For example, if my html page says:
Name: [ ]
...I want someone to be able to click on the [] and enter their name, etc. and click SAVE
and then have the form say:
Name: "Name of Person"
If someone wants to update that, they can click on the person's name and change it and click SAVE and have the HTML form update itself.
How can I do this? I've looked everywhere and people are talking about HTML5 AND PHP. Is it really that complicated to make a simple page like this?
(In case I wasn't clear in my html I'm using the contenteditable="true" option. How can I save those changes?)
I think your question indicates that you don't already know that web pages (including forms) are "stateless", meaning that they do not "automatically" hold or store anything that you do with them. Sorry to disappoint, but as a beginner you will struggle to find "an easy" solution to this.
That is not to say it can't be done - you no doubt see it everywhere - but your level of knowledge misses the fact that you need to actually program the logic to determine how your form will "appear" to store the information and reproduce it on a later visit.
Here's a (really) brief summary:
When your form is used by your user, a couple of things have already taken place before they get to see the form:
the user has requested the page (typing a URL or clicking a link)
the web server has sent the requested page (that is; your website has sent the form)
The next thing that takes place is that your user enters some data on the form. This data is not stored anywhere - if you refresh the page the data is gone, because steps 1 and 2 happen again.
So to avoid this you can use a number of tools:
Javascript: this operates on the user's computer. You can use it to find out if something has been entred on a form, and store it in, for example, a cookie.
Then you will have to build some logic into your page that says, "if my user refreshes the page or comes back to this site at a later date, then look for the cookie. If it exists, then take it's values and pre-fill the form, before the user gets to see it."
Server Side Script: This logic can be built into your web server (using a server side script like PHP) so it actually runs in step 2.
Alternatively you can build it into a javascript function which fires when the page is actually received by your user. This would be a step 3.
A second alternative combines these two ideas (processing on the user side and processing on the webserver side) called AJAX, which basically means that the "discussion" between your javascript and PHP takes place "on the fly" when the data is entered or changed.
And lastly you might want to consider PHP Sessions to store data, and/or a mySQL database. Recently with the advent of modern browsers you now have the possibility to store the information in a local database available to your user's browser...
In all of these cases you will need to learn how these pieces talk to each other, how you retreive the information, and how you update your stateless and static form.
It isn't has straightforward as you might think...
You don't need HTML5. HTML4 is good enough :)
But you need some server side script that saves the changes (on the server side in e.g. a DB or XML file). To make it a better experience (if multiple users use the form at the same time) I suggest you use AJAX to save the changes and poll the server for updates.
This is not complicated (at least I don't think it is), but it seems to be a generation ahead of what you already know. And it could take quite a long time to get the structure in place before you can do this sort of thing without needing help.
There are some basic questions
Does the information need to stay saved when the user hits reload?
Does the information need to stay saved when the user clears cookies?
If the information can be blanked out next time they come back to your page, then it is simple.
Otherwise, we need a way to keep track of which user sees what information, so the guy in Texas does not see the information the guy in Chinatown typed in. Cookies are a common way to do this. You could save the information to the cookies if there is not too much information.
Otherwise, you need sever-side language. This is usually in PHP, but deciding what language has to do with why you want to learn in the first place? Are you wanting to work for a company later on? Do you have your own website?
Please comment to let me know more what is going on, and what the answers are to the two basic questions, and I will better be able to answer.
Usually, for most cases, there is a login name and password (or OpenID), and if cookies are cleared, the user logs in again, but this requires some work to set up a working login before you re-visit this question of how to store what they type.
I was having a discussion with coworkers. We have to implement some security standards. We know not to store 'sensitive, addresses, date of birth' information in hidden fields but is it OK to use hidden fields for your application, in general.
For example:
action=goback
It seems like it would be safer to use hidden fields for that kind of information as opposed to adding it in the query string. It is one less piece of information that a hacker could use against your application.
A hacker can access hidden fields just as easily as querystring values by using an intercepting proxy (or any number of tools).
I dont think there is anything wrong with using hidden fields as long as they aren't used for anything sensitive and you validate them like you would any other value from the client.
Making a field "hidden" has pretty much nothing to do with security, and should be considered a UI decision. Any "hacker" will read your HTML source anyway.
Better to either not show sensitive information at all, or, if you must, to use SSL (to prevent data interception by network intermediaries) and some combination of login challenges (to prevent unauthorized access).
It's only a security hole if you're exposing information that wouldn't be otherwise available to the end user and/or aren't validating it on return.
I'd look instead to storing said information in a server side session variable instead...
Storing your data in a hidden field is, from a security standpoint, exactly the same as storing it in the query string. In fact, if your form uses the GET action, it ends up int he query string anyway.
Hidden fields are completely unrelated to security in any way; they are simply a method by which data can be stored in a form without forcing the user to see it. They do not provide a way of preventing the user from seeing it.
Hidden fields are not always an issue, but they should always ring alarm bells as they have two potential problems:
1) If the data is sensitive, it exposes it to the client (e.g. using a proxy, or simply view source - and it is pointless to try and prevent this programmatically)
2) If the data is interpreted by the server, a knowledgeable user can change it. To take a silly example, if the hidden field contains the user's bank balance, they could use a proxy or some non standard client to make the server think their bank balance is anything they choose.
The second one is a big source of vulnerabilities in webapps. Data associated with the session should be held server side, unless you have a means of validating it on the server (for example if the field is signed or encrypted by the server).
Provided you are sure you're not falling into either of these traps, they can be OK to use. As a rule of thumb, I would not use hidden fields except for data you would be happy to see in the query string, or if javascript needs them for processing. In the latter case, you still need to make sure the server is validating though, don't assume the client will run your javascript.
Consider encrypting the name and value of your hidden field for the purpose of tamper checking since hackers can still get hold of your hidden fields and manipulate them the way they wanted to.
As other people have mentioned both the query string and hidden fields are essentially public data, viewable by the user.
One thing to keep in mind if you place data on the querystring is that people pass urls around, and because of this should never contain any information specific to the current user.
It is also probably a good idea not to include state information in the url, if that state can not be entered directly. Or at least you would need to handle invalid state information in the querystring.
I would say that this is no more or less safe than placing the item in the query string. After all, one could always view source on the site (and there isn't any way to prevent that, since one could always programmatically download the source).
A better solution here would be to encrypt the names of the fields and the values with a key that is generated on the server, and only the server. Unless the server was hacked, the client wouldn't have any clue what the name of the value is, or its value.
Of course, since this is coming from the client, you still have to check the validity of the data coming back, don't just take for granted that it hasn't been altered in a manner that you didn't dictate.
To that end, you will want to use hashing to make sure that the value hasn't been tampered.
In general don't use hidden form fields for sensitive data. Only for static non sensitive POST data that you realise is not safe to handle "as its recieved". The only time i use them is to store Session Tokens as they're rendered and checked upon recieving the POST. To prevent CSRF attacks or atleast make them a great deal harder.
In addition to all the other useful advice by other posters, I'd also add that hidden fields make your app no less vulnerable to SQL injection attacks as url query string values do. As always, sanitise your input.