I understand that Bolt does only browser based validation but this is inadequate for real world cases where a fuzzy red border won't stop bad user input. Is there any way to actually enforce that required fields are filled before submission or just stop submit if required fields are still empty?
Otherwise, it seems counter intuitive to even have a field attribute of "required:true" that can still be submitted with empty values and thus never ever enforced. Even Wordpress won't allow that.
This is actually not a Bolt problem as such. Bolt is a CMS, front end forms are just that, front end... However...
In the upcoming Bolt 2, there is an extension in the marketplace called Bolt Forms that enables a full set of Symfony validators to be defined for form fields... I may even know the author personally ;-)
Bolt Forms is in a late-alpha stage at the moment, but I should have it ready in the time that Bolt 2 goes public. There are even several people using in production already.
Related
Say we want to use tinymce to allow users to enter HTML formatted input. The django-tinymce package is a handy solution.
But to render this later as output, we have to use {{ userinput | safe }} to display it. But do we know for a fact the original user's input is ... safe?
What in particular are the kinds of malicious HTML tags we need to be wary of and sanitize? What would be a sound strategy to not strip out the legitimate tags tinymce utilizes while protecting future website users who will be presented with 'safe' user input?
You can never assume that data provided to you client side is "clean" or "safe". Nefarious people can bypass your front end and all of its validation if their goal is to cause harm to your system.
You should always configure your front end appropriately. Validate data, configure TinyMCE to only allow those types of tags you want created, etc.
However, regardless of the front end design, you always have to re-check submitted content on the server to be safe. There is simply no way around that need. What constitutes "safe" is likely a business decision based on what your application does and who uses it.
There are many different libraries you can use server side to do this sort of validation/cleansing so depending on your specific server side setup (guessing PHP) you can find libraries that allow you to "sanitize/purify" the submitted HTML.
I am working on a user-moderated database and settled on MediaWiki with Semantic MediaWiki as an engine. I installed Semantic Forms to force the end users to conform to a certain standard when creating or editing entries. The problem is that since a user can add a semantic notation to any form text input it can throw off the proper structure of the system, i.e. if it was an IMDB clone a user can add [[Directed by:Forest Gump]] which would then result in the movie "Forest Gump" showing up under a list of directors.
I doubt that there's any setting that can simply turn this off or on, but I've had one or two ideas as to how to get it working.
One, perhaps there's a way to disable semantic notation on specific namespaces and put the forms on those namespaces. I have a feeling that this will cause the forms to merely break.
Another idea is to modify the code. This is clearly the less ideal approach. To get started, I believe I would need to create some sort of filter on SFTextAreaInput which would disable semantic notations for the user inserted text, but alas I'm unsure as to how to get started on that.
Well, Semantic MediaWiki is still a Wiki. In your classical enterprise database, you restrict the users' input options as a means of ensuring data integrity. That isn't what wikis do; the thinking with a wiki is, yes, the user can enter incorrect information, but another user will amend it and let the first user know what was wrong.
I wouldn't try to coerce SMW into rigid data acquisition. I mean, you do have options such as removing the standard input fields in forms:
'''Free text:'''
{{{standard input|free text|rows=10}}}
If users are selecting a movie page when they should be selecting a director page, then you probably want to encourage correct selection by populating the form control from the Directors category, like:
{{{field|Director|input type=combobox|values from category=Directors}}}
Yes, they can still go very far out of their way to select "Forrest Gump", but if that happens then the fact that someone wilfully circumvented the preselected correct options is a more pressing concern than the fact that the system permits it.
Wikis work best when the system encourages rather than enforces valid knowledge.
My name is Wolfgang Fahl I am behind the smartMediaWiki approach. You might want to go the smartMediaWiki route
see
http://semantic-mediawiki.org/wiki/SMWCon_Spring_2015/smartMediaWiki
For a start don't go just by the property values but e.g. also by a category.
{{#ask: [[Category:Movie]] [[Directed by::+]]
|?Directed by
}}
will only show pages that have both the property set and are in the correct category.
In the smartMediaWiki approach you'd create a topic "Movie" and the entry of movies would be done via Forms. This is an elaboration of the SemanticForms and semantic PageSchemas idea that recently evolved. You can find out more about this at SMWCon Barcelona 2015 this fall.
I have a pretty good project task management system going in Microsoft Access, but one feature I'm still missing is some type of 'quick entry' like facility often found in many good productivity applications.
This is how it would work:
Scenario 1:
You're in another application, working on a few things, and you just remember something that needs to get done. You hit your predefined shortcut: CTRL + ALT + T (again, from outside Microsoft Access) and it brings up a small access form with a text box in to which you can type what needs to get done, e.g.
Inform key stakeholders of concerns regarding timeline
you hit return and that gets saved as a record in Microsoft Access instantly.
An alternative, and slightly more complex scenario...
Scenario 2:
As above, but you want to add further details besides the task name, such as the person you need to speak to, and a due date. The input in to the text box could look like this:
Inform #Sally of concerns regarding timeline >+3
Where '#' tells access to populate a field called 'Contact' with 'Sally' (unless it already exists) and '>+3' is interpreted by access to mean a due date 3 days from today.
How difficult are Scenario 1 and Scenario 2 to perform? What level of VBA/programming knowledge would be required?
Thanks,
I would say it requires a fair amount of confidence in VBA.
You need to register a global hot-key; that is, a keyboard-combination that can be captured from outside the Access application. It requires win-api calls. Here is some code.
You need to know where to place these calls. I believe you have to put them in a standard module, not in the form's class module. (I haven't double-checked this, it's late.)
You need to have a little understanding about what this code is doing. NEVER attempt to type this api-code - copy it from a reliable source, exactly as it is!! You don't need to fully understand the code, but you need to know how (and when) to call each function.
Once you've registered the hot-key then your VBA needs to bring your application to the front and display your form, and focus it. Reliably bringing the application to the front may also require api-calls.
Once your form is opened (and focused) you can have a button on it to parse the information in its textbox. However, if you are designing the form anyway, I would add checkboxes, comboboxes, etc., rather than trying to parse a complex sentence/ statement.
I'm working on a web application (Java EE backend) which contains a fairly complex input modal. This input modal allows the user to capture data, but it has a bunch of (JavaScript) restrictions, such as mandatory fields, fields only being available if a specific value is entered, etc.
I have to expose this functionality to external systems and allow them to submit this data to my server. These external systems can be both web or client based (but I can assume that the clients will have internet access). My first thought is to provide some kind of definition of the fields and stuff like mandatory to these systems through services, and have them render the input modal however they want. This has been met with resistance though, because the types of fields and restrictions will likely change quite a bit during the next few months of development. These external systems have different deployment timelines, and for this to work we'll have to firstly duplicate all the logic handling these restrictions across all systems, and secondly synchronize our deployments.
An alternative which has been proposed is to have the external systems call my modal through standard HTTP and render it either in an iframe or in an embedded rendered. This solves all of the previous complaints, but it leaves me feeling a little uneasy.
Are there any alternatives we are not thinking of? Maybe some kind of UI schema with existing render libraries for the different platforms? What are your thoughts on the second proposal, any major concerns or is this the "best" solution?
Edit: To clarify, I'll of course still perform backend validation regardless of the frontend decision, as I can't just trust the incoming data.
The constraints that you mention (mandatory fields etc.) really have nothing to do with the user interface. You are also right that it is not a good idea to have your backend render web content.
Your first proposal sounds like a good idea, here's how I would solve the issues you mentioned:
Do all the validation on the backend and send a model object to the client, representing the current state of the UI (field name, type, enabled/disabled, error message etc.).
Keep the client as dumb as possible. It should only be responsible for rendering the model on a window / webpage. Whenever a field is changed and it requires validation, submit the model to the backend for validation and get back a new model to be displayed. (You could optimize this by only returning the fields that changed.)
Doing it this way will keep your validation logic in one place (the backend) and the clients rarely need to be modified.
I have been faced with same issues in several previous projects. Based on this experience I can honestly say that server-side validation is the thing you will likely have to implement to avoid rubbish being committed from client side regardless if it comes from GUI or other third party system via API. You can choose one of available validation frameworks, I used Apache Commons Validator and think it is well, or you can implement your own one. On the other hand client side pre-validation, auto-completion and data look up are the solutions you should have to make human users happy. Do not consider about code duplication, just make your system right way from the business point of view.
I have a contest entry page on my company's website. In order to enter the contest, you create a login, which is just an email and a 4-digit pin. Here's the PIN field:
<input type="password" name="contest_pin" id="contest_pin" maxlength="4" />
When users submit the form, the account is created in our database, and then they get an email (which I'm copied on) that contains the email address and PIN they created.
Here's the issue: in every browser I've tested (Safari/Chrome/Firefox on Mac, Chrome/Firefox on Linux, IE7/8/9 on Windows) I CANNOT enter more than 4 digits into that PIN field. And yet, several of the emails I've received show that the user has created a pin with more than 4 characters.
How is this possible? Are there browsers that don't support maxlength? I haven't tested in Opera, or on any of the mobile browsers. It's not a huge deal if their pin is longer than 4 digits; the database will accept more. I'm just wondering how they managed to get around maxlength.
EDITED TO ADD
There are too many answers basically saying the same thing for me to respond individually to all of them. I KNOW that I should always do server-side validation for anything important, and we do have PHP code in place sanitizing our data, and if it was hugely important I would also have PHP code enforcing the 4-digit limit. It's not that important to us that they be only 4 characters, so I haven't enforced it. I'm just wondering why the maxlength property is not doing what it's designed to do, which is prevent users from entering more than a certain number of characters. For those of you that suggested malicious scripts or Firebug, I can be 100% certain this is not the case. Only registered users of our site (which is limited to a very specific corporate membership list) can even get to the contest entry page, and I can guarantee that none of the approximately 100 people on that list are going to be deliberately trying to circumvent an input type property.
They very likely are bots that read field names and create GET and POST requests based on those rather than using the HTML form like a normal human user would.
This is why client-side validation of form is never enough to ensure data is correct. Client-side validation is nice as it's responsive for end users, but it's not able to prevent bad data from arriving at your server's doorstep.
As an example, let's say I have an input field in a form whose action is GET. My input field's maxlength is 4. When I press submit, I see the URL ending with ?field=1234. There's nothing stopping me from updating that URL to ?field=123456789 and pressing enter. Similar things can be done with POST actions, but a tool is needed to do it.
I believe that every browser supports it, here's a few links for reference :
Maxlength | SitePointReference
Maxlength | W3 Schools
Obviously there are way around this - you should ensure you ALWAYS have adequate server-side validation, as client-side usually isn't enough on it's own.
All browsers support maxlength. However, this attribute can easily be removed/changed using DOM methods or, for example, with Firefox's Web Developer Toolbar.
several of the emails I've received show that the user has created a pin with more than 4 characters.
How is this possible? Are there browsers that don't support maxlength?
I would investigate the USER_AGENT and REFERER headers related to those user activities. Perhaps a malicious user submitted forms programmatically circumventing the browser restrictions, just to check your perimeter defense. If so you should see some patterns there.
Anyway these educated guesses aside, maxlength should not be treated as a means of securing the input. Anything client-side is not under your control, it exists merely to make user interface more intuitive, interactive. You should always check everything on the server. In that case, the PIN being composed of 4 digits, otherwise reject the input. The golden rule is to treat all user input as hostile and thoroughly validate it on the server.
In general, trying to enforce rules for user input done client-side is a bad idea. I had an experience where we had contracted out some work to some programmers and their idea of sanitizing user input was making it so that users couldn't input more than 10 characters in any given field. A quick firebug change and, oh look, I can drop the server's database with some minimal SQL injection.
If I were you I'd check maximum lengths with whatever script adds user information to your database and return form validation errors if the user input exceeds the maximum specified length.
This is the type of thing that you should still validate server side, even though the clients will almost always support it. It is very easy to get around a maxlength -- Firefox Developer toolbar includes an option to "Remove Maximum Lengths", or a request can very easily be hand-edited. I almost think that in the past you could get around a maxlength in one of the browsers simply by using cut and paste(eg, the browser wouldn't let you type more characters, but if you pasted a value that was 5+ characters it would enter them all), though I can't remember specifically which browser I saw that on...