What I have is a form website page that will automatically fill out the required form with the information entered from the form website page. What I am trying to figure out is if #session.checkout.info.firstname_2# does not exist how do you skip it and not make the form worry about it?
So there are two fields one for owner and the other for co-owner, if there is only one owner the page is not opening the form because its looking for something to be entered as firstname_2 but if both owner and co-owner are entered it works fine because all fields are then entered. Does anyone know how I can make it only worry about the fields that have been submitted from the first form and ignore the sessions that have not yet been entered?
<cfif len(#session.checkout.info.firstname_2#)>
<cfpdfformparam
name="co-owner name"
value="#session.checkout.info.firstname_2# #session.checkout.info.middlename_2# #session.checkout.info.lastname_2#">
</cfif>
You can use isDefined to check that the variable does not exist.
<cfif isDefined("session.checkout.info.firstname_2")>
<cfpdfformparam
name="co-owner name"
value="#session.checkout.info.firstname_2# #session.checkout.info.middlename_2# #session.checkout.info.lastname_2#">
</cfif>
If you also need to check length you can combine the above if with what you've written.
Generally it's a better practice to use structKeyExists() but when there are multiple item that may not exist it can be cumbersome, i.e. structKeyExists(session, 'checkout') && structKeyExists(session.checkout, 'info') && structKeyExists(session.checkout.info, 'firstname_2')
Related
When I submit my form I am getting an error from my cfinsert function because there is not a database column name "SEARCHFIELD". The problem is "SEARCHFIELD" is not an input in the form I am submitting.
Both forms have close and open tags so I am not sure why my search form input is being referenced in my main forms submission?
Any thoughts?
Two ways I can think of to avoid this, without seeing your actual code it is hard to guess where SEARCHFIELD is coming from. As some of the comments pointed out it would most likely be from a CFPARAM or the name of your submit button in the form.
The first way you could tackle this is the CFINSERT tag has an attribute named formfields where you can list off the columns you wish to insert with. You can see that here in this doc link:
http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-7c78.html
Another way you could do this is you could add code to remove SEARCHFIELD from the FORM scope prior to running the CFINSERT. Which would be as simple as:
<cfset StructDelete(FORM, "SEARCHFIELD") />
You could check to see if it exists and if so then delete it but the StructDelete() will run without issues even if the field does not exist.
I personally do not use CFINSERT/CFUPDATE and I know the default opinion in the community is not to. They do have some benefits though that often are overlooked in that they do parameterise the SQL and offer at least some safety from malicious people. Without knowing anything about what you are doing it is hard to say if using them is actually a shot in your foot in the long run or something just fine to be doing.
A lot of folks on Stack Overflow are probably trying to fix forms that don't submit, but I'm actually hoping to do the opposite!
What I'd like to do for an art project is make a form with a "joke" field -- say, your SSN, your bank account number, your fingerprints or retina scans or DNA code, or something super personal like that. But I don't want the number in our server logs, and I don't want it to be transmitted over the internet at all. I don't want any legal liability!
Basically the idea is just to ask for something audacious, but not to handle the data that may or may not come from users who actually put it in.
So, is there a way to make a field that acts as a normal form field, but where nonetheless we would feel "safe" that users who actually do put their sensitive info in the field will be protected?
What's the "safest" approach to something like this?
Form fields require a name to be submitted:
If any of the following conditions are met, then skip these substeps for this element:
[…]
The field element is not an input element whose type attribute is in the Image Button state, and either the field element does not have a name attribute specified, or its name attribute's value is the empty string.
[…]
So you could simply use an input without name attribute:
<input type="text">
Be careful with your "jokes", if you want that the information of the field is not submitted, then, you can simply leave it out of the form element like this:
<form action="... >
<input type="... >
</form>
<input type="... > <!-- This field won't be submitted-->
I have a safe cracker form that allows a logged in member to submit an entry (a vote, actually). When they submit their vote, I want to prevent them from ever being able to submit an entry to this channel again. Is that possible? If so, how? Something automatic that either sets a member variable or searches some field to see if a member has submitted or something.
Couldn't you just wrap something like this
{exp:channel:entries channel='votes' author_id='{logged_in_member_id}' dynamic='off'}
{if total_results == 0}
{!-- allow a new entry --}
{/if}
{/exp:channel:entries}
around some or all of you voting form?
I have a three step form where each step posts to its own action. The action redirects to the next step. The data is stored in the session scope. I have a filter that prevents a user from accessing the form handlers through anything other than a post request.
There's nothing to stop someone from manually typing in the address of a step, however. To deal with this problem I set a currentStep variable in the session.
<!--- Some data is processed here --->
<cfset session.currentStep = "stepTwo">
And in step two I would check for a structkey:
<cfif NOT session.currentStep = "stepTwo">
<!--- redirect to #session.currentStep# --->
This approach works, but it has a major drawback: A user can not press the back button in the browser window, or edit any data he or she has already entered.
What are some the best practices to implementing a multistep form? Can I improve my process to incorporate back-button functionality?
Instead of using the session variable to only allow them to access the current step, allow them to access the current or previous steps. Sort of a "how far you can go" flag.
Now, add links to the previous steps, like a breadcrumb trail.
Finally, use a lookup in the persistent store (db, session, xml, bag of holding, etc.) for the data already entered for that form. Create a blank set of form data, overwrite it with anything found in the persistent store, then overwrite it with anything from the form scope itself. Something like:
populate = structNew(); // this is the data to populate your form with on load
populate.someValue = "";
structappend(populate, dataFromStorage);
structappend(populate, form); // from things submitted from the form scope, in case validation fails
<input type="text" name="someValue" value="#variables.populate.someValue">
Now, if someone hits the same form step twice, they will see (in order of precedence) the values they submitted, but which didn't pass validation, values from the persistent data store, and then an empty form.
You can stay using Session approach if you want.
To solve your major drawback, you can change your logic a bit.
At the last step, make sure data of all steps are found in the session. If not, redirect the user to the first unfilled step? Shouldn't be too hard.
Is it possible to validate a radio group (so something is checked off, or chosen) using server-side validation with Perl? If so, how?
I already have it for JavaScript, but I want this form to be able to be submitted even without JavaScript enabled. Thus I will need the validation on the server-side.
There is no fixed name for the radio group, it can change, however there must be a name, so that #names = $cgi->param() will give all the names.
I'm thinking along something that will give me the type, like the type in JavaScript, to determine if it's a radio button in a group.
Your CGI script receives form fields as name-value pairs without any information as to what type of visual form element generated the values.
Your CGI script must know the names of the input variables whose values it is going to validate. Having the names supplied to the script based on untrusted user input is risky IMHO—that includes using another field whose value is the name of the radio group.
Say, you have a variable called contact_me which can take on values "yes" and "no". There is absolutely no reason for your CGI script to care if the value was provided using
<select name="contact_me">
<option value="yes" selected="1">Please do!</option>
<option value="no">Oh no!!!</option>
</select>
or using
<input type="radio" name="contact_me" value="yes" checked="1">
<input type="radio" name="contact_me" value="no">
or if the user typed her answer into the text field
<input name="contact_me">
The only thing your CGI script needs to concern itself with is if the value of contact_me is "yes" or "no".
It looks like you do not have a firm grasp of CGI. Please see The World Wide Web Security FAQ: CGI (Server) Scripts as a starting point.
Please stop all of your CGI development until you understand the ramifications. I retract this remark in light of your comments clarifying the use of a config file to define parameter names (which, in principle, is orders of magnitude safer).
Pass another hidden input field containing the name of the radiogroup, then just read
#values = $cgi->param($cgi->param("radiogroup_name")); // IIRC