Users can submit color palettes and I'd like to standardize the format of the hex codes submitted.
Is there a typical way to clean up/standardize this sort of user-submitted data?
In my case, there are four fields where users can enter a hex code. I ultimately want to store it without the pound sign. (So #000000 to 000000).
It's obviously easy to remove the pound sign, but where in the process it should be is what I'm not sure of.
Needs to be server-side as this data can be submitted via other methods than the browser (i.e. API).
Everywhere!
You'll definitely want to clean it up server-side, as that's (presumably) where any sort of processing that expects consistently-formatted data to appear, and that's also where you'll be sanitizing user input (which you're doing, of course, right?). Don't trust anything from a remote source on a server!
A bit of client-side auto-formatting wouldn't hurt, though; use javascript to automatically format things and impress your users while doing it!
Why not use Javascript to sanitize the data before passing it through to anything? You should be able to easily evaluate the string and make adjustments there before submitting it to your controller/action.
Related
I have a regular text input field, whose value is submitted via AJAX. After I migrate away from this page, and hit Back button, I can still see the value of the field there.
My questions are:
Does most of modern browsers support this user-entered values?
How can I remove the persisted value using Rails?
Thank you.
Your browser is remembering the form input values and displaying them when you go back. This likely doesn't have anything to do with Rails*.
You can't really do anything via Ruby/Rails code to change this behavior, but you can do it with JavaScript. Here's a random SO question that covers it: Reset form on Back button.
I'm not sure if there's a perfect way to handle this in every browser. Also note that many users would prefer that the browser keep the form values they've entered.
Note: I only qualify with "likely" because it is possible to write an app that explicitly remembers form values and restores them when the page is visited again, but by default, Rails isn't going to do that. It'd involve a fair bit of Rails and JavaScript code.
Does most of modern browsers support this user-entered values?
Yes, I believe they all support it to various degrees
How can I remove the persisted value using Rails?
This is a client side issue, not a Rails issue. You could use javascript to clear the input fields
A similar question and answer: Clear all fields in a form upon going back with browser back button
BFCache? https://developer.mozilla.org/en-US/docs/Working_with_BFCache
I'm studying a solution to manage data coming from a textarea edited by users.
I'll have to give the chance to the users to add some basic HTML tags (links, bold, list and something else).
My big concern is about the security.
The data will be saved in a mySql db.
Any advice in order to avoid as much as possible security problems?
What is the best way to save this kind of text in a database ?
Thank you
The best way to solve this is to make a whitelist of the allowed tags. Through JavaScript you can warn the users that they are entering invalid data, but to secure your data at the server side you need to strip them out of the content. A script tag for example should be handled with care. If you want your users to enter those, and other users to be able to view it, some more complex handling is needed.
A neat solution is to escape all the white listed tags and to encode the other ones as characters, so that a <script> tag becomes <script>. That way, if you output it in your html it won't be seen as a valid tag but as characters placed after each other.
If you need a more specific solution for your own language please provide some more details, but this is sufficient as a global concept.
I'm having some problems with Html.Encode and users wanting to use special characters. Firstly the characters are replaced by the html codes and so are not displayed properly. And then, if the text is later edited and re-submitted, an exception is thrown when these html codes are re-submitted.
Given that this is an intranet site and the possibility of a deliberate attack is almost non-existant, is there really any risk to not using Html.Encode? Is there any possiblity that someone would inadvertently submit some special characters which cause problems?
Or is there a better way around this problem?
Given that this is an intranet site
and the possibility of a deliberate
attack is almost non-existant, is
there really any risk to not using
Html.Encode
Yes, yes and yes again. There's always a risk by someone entering special characters in input fields. The golden rule of web development is never trust user input and always encode anything that might come from an user input.
Check everywhere you are calling Html.Encode as it sounds like you're double encoding your strings (possibly encoding on save and on display or encoding on a template/partial and encoding that again).
And yes always encode your strings even if it's internal, otherwise one disgruntled employee could cause some serious damage.
Firstly the characters are replaced by the html codes and so are not displayed properly
You are double encoding. You actually want to Html.Encode to display the HTML tags the user entered at all. Unless you actually want things like <ul><li> to be a bullet list instead of showing the tags.
And then, if the text is later edited and re-submitted, an exception is thrown when these html codes are re-submitted.
Whatever you did to allow the initial submission of those, will work to allow edit. Again, maybe because of the double encoding, you are getting into further issues.
Given that this is an intranet site and the possibility of a deliberate attack is almost non-existant, is there really any risk to not using Html.Encode?
Deep down You already know that way of seeing security is wrong ;)
I think the URL length can only be 2000 or so characters long. Otherwise, it will choke some versions of IE. Is there any way to overcome this problem?
At first i was thinking about tinyurl, but tinyurl actually immediately redirects to the longer URL, so that probably will fail too.
Update:
I need such long URL because I need to be able for people to bookmark the URL or to send it to other people by email.
That's what POST is for ;)
For bookmarking reasons you could store a hash of the argument string in the databse as well as the argument list. That way when somone bookmarks something they get a bookmark with the hash in it and your internal software looks up the appropriate arguments and gets them.
You are in essence rolling your own tiny url.
If somone else wants to bookmark a page with the same arguments then the hash will be the same.
the only problem is that your table of hashes will grow quite big, and many of these "book marks" might never be used.
HTML POST is designed for transferring larger amounts of data. You should look at that.
What do your urls look like?
Maybe you could use gzip or md5 to shorten them, or store them in a database and put the id of the row in the url?
There's no realistic way to get around this - it's not a limitation in the specs or anything like that, but in IE itself and presumably how the URL is allocated (I believe the limit is actually 2083 characters by the way, for some reason).
Since IE needs the URL all in one go to send to the server, I can't think of any clever tricks that would enable you to work around it. Some options I considered were to send the query parameters via POST instead of GET (but this is often not interchangeable on the server side, and the clients will treat this differently in that the URL can't then appear in a hyperlink or be bookmarked or entered manually, and if the user wants to refresh they'll get the "send information again" warning, which makes sense since POST is meant to update information on the remote server, and it'll only work if it's the query string pushing it beyond the limit rather than some ungodly URL). Alternatively you could perhaps chunk up the URL, setting the overflow part in a cookie and then making the request to the stub of the URL, which is intelligent enough to pull the context out of the cookie and append it to the URL actually received. However this again complicates processing on the server, probably far too much to be used beyond a trivial application, and also still means you can't put that URL in hyperlinks or bookmarks or whatever, since an important part of it is client state.
Basically, everything else would involve rewriting the server to somehow piece together the extra information, and if you're able to do this then you should be able to simply change the URL scheme so that everything's below 2000 characters. So no - no real way around it.
(Though if you could use something like tinyurl to act as a proxy rather than issuing a browser redirect to the URL, that could work).
I'm building a publicly available web app. Because of this, I'll be validating every field as exhaustively as I can. I mean, if someone enters something that isn't valid, they will know exactly what it was (making it clear what they need to fix).
I've followed Scott Guthrie's examples in the NerdDinner eBook. I love the idea of having all my validation in the core class files (as a partial class).
The validation I'm performing is this:
Min value - make sure strings are at least a certain length
Max value - make sure strings are under a maximum length (based on field properties in the DB)
int checks - make sure integer fields can be correctly parsed to int
file extension - make sure the uploaded file extensions are of the correct type
My question is, what are the typical validation checks you make in your web apps? Maybe I'm completely overlooking something. ;)
Thanks in advance!
You should try to use existing frameworks as much as possible for validation. Writing a comprehensive validation library is a lot of hard and time-consuming work. It's one of those things that are best left to a team of people dedicated to developing it such as the jQuery validation plugins and projects like that. There are a lot of really nice validator libraries out there already that could save you a lot of time and effort.
There is an MVC validator toolkit project on codeplex you may find helpful. CodeProject has a tutorial on it if you want to read more into it. You can also check out xVal, as one of the commenters mentioned.
If you have a specific reason you need to write validation in-house, or you aren't convinced by what I said above, a few that I find useful are:
Required field validation, obviously. You might already have this by just checking for minimum length in your fields.
Generic regular expression validation. Make sure you have some way to perform this kind of validation generically. This will help you in case there is some specific field that needs a unique form of validation found no where else in your site. Make sure your API is flexible enough to add specific regular expression based validation.
Email. You'll need this.
Phone numbers. These can be tough because of all the forms they can come in (all numeric, sometimes with alpha characters, sometimes international numbers that follow different formats)
Dates & times are important also, however you should consider using some sort of date/time picker to reduce the possibility of error by not allowing the user to type a value.
Make sure you include validation capabilities for non-textbox related fields, such as drop-down lists, radio buttons, check boxes, etc. I've forgotten these in the past just out of oversight, but they do become important.
Matching fields. For example, when confirming a password, both fields should match. This won't be used in just one page. Think about password resets, administrative pages, user control panels, etc.
Although somewhat complex, you might also want to include sequence validation. For example, perhaps some options on your site require you to select other options first. Another example is that certain options should only be selectable if you first choose some other combination of options. This is something that you may not be able to include in a generic API, but it's something to think about.
You'll want to check for SQL injection, XSS, and CSRF. You can use these tools for Firefox to help you test those. Then there are also things like making sure that the username doesn't equal the password, login throttling, etc. Validating your CSS and XHTML isn't bad either, though I don't think that's quite what you meant.
In addition to what others have mentioned, don't forget to validate items that depend on one another. That is, consistency of input values. If the user enters a maximum and a minimum, for example, don't just check the two values independently against their legal max and min, but also check them against each other to ensure that the values entered are logically consistent.
For hostnames, you may want to validate that DNS returns an IP address. If it does not, let the user know but don't necessarily reject the hostname for this reason. Maybe the user is pre-configuring something that doesn't exist yet. It depends on the specific application.
That is, in addition to syntactic validity, you can also check that the values entered are meaningful and consistent with each other.
Another thing you can do if you go all out is to only allow digits to be entered in numeric fields, only allow digits and "-" in credit card or phone number fields, and so on.
And always, always allow the user to enter input in the most familiar format, even if you later have to strip out extraneous data. For example, let the user (but don't require the user to) enter a phone number is 1-800-555-1212 even if you later strip out the "-" characters.
Not really sure what this has to do with asp.net-mvc but...
I always try to avoid over-validating (obviously you need to do the simple sanity stuff to make sure there are no db errors). It is a field by field decision according to your business rules. Some fields will need to have strict validation rules, like a credit card number. But just always think about how the validation will server the user. There is rarely a need for the regex to match all possible email addresses - it is really annoying when a site won't allow + signs in your email. In most cases, your app will be just fine if you let people put in phone numbers how they want. And always second guess yourself when you're about to put a required rule on a field.
I recommend the entlib validation application block for a easy to use and extend framework.