I'm looking for a simple anti spam form submission solution, other than Captcha. I've tried implementing Captcha into my website for anti-spam purposes, but it's been too difficult to integrate into the site. I don't get many spam attacks but I'd like to have something in place for the random spam that I get. Does anyone know of something they think would work?
you can add an additional textfield to your form and hide it with css. human users don't see the field, so it should always be empty. spambots usually fill out all form fields and don't know that this one is hidden. if you receive any content in this field, reject the form submission.
Put up something like "What is 3 plus 6?" and give the user a form to type the answer. Any human will get that, including blind ones who can't see a captcha, but no bot will. You don't even need to vary the numbers, really.
Related
I have an ecommerce gift store where users can fill out a gift-card for their recipient.
In order to fill out the card, I have the users enter text into a multiline textbox.
When I display the gift-card on the final review page, I have to spit out the information with Html.Raw so that Newlines are being displayed properly. I'm doing this:
#(Model.GiftCard.Text != null ? Html.Raw(Model.GiftCard.Text.Replace(char.ConvertFromUtf32(13),"<br />")) : Html.Raw(""))
I'm frightened that i'm entering dangerous territory using Html.Raw on values that were user-entered. However, when I go back to the gift-card entry page, the page breaks when I try to do something like "This is my gift card! (scripttag)alert('test');(/scripttag)"... so I feel like .net will catch any malicious entries during that point.
Am I safe to proceed like this? It seems that since the gift-card entry page is running validations against malicious code, I should be okay to use HtmlRaw later to display newline html that I'm putting in myself...
(I replaced the actual script tag with this (scripttag) thing above so it will show in stackoverflow)
Use a regular expression in your view model to make sure people only enter A-Za-z0-9 and whatever else you think should use such as :) =] type of stuff. Screening this stuff front end is better than second guessing it on the way out.
How about using a
<pre></pre>
tag instead? This would allow returns to display in HTML without the need for Html.Raw?
I'm looking for a Ajax rating script similar to the one on metacritic, ign, gamespot, etc.
(example)
I've found only star rating systems and one slider that is not similar to the one that I'm looking for. (jquery ui slider)
Anyone knows something like that I'm looking for? Otherwise I'm willing to pay someone for this work.
It's not hard to roll your own, you just need a combination of jQuery/AJAX, CSS and the server-side poison of your choice.
Here is an example:
http://www.99points.info/2010/05/ajax-rating-system-create-simple-ajax-rating-system-using-jquery-ajax-and-php/
Essentially you wire up client-side event handlers which do AJAX HTTP POST requests to your server-side handler/web service, which then return back the response.
Now, that example isn't exactly a "slider" but it illustrates how it can be accomplished.
Check out this site for a multitude of AJAX slider examples - you just need to combine the two principles (rating and slider) and you're good to go.
Obviously if you don't like the "look" of it, you can mess with the CSS/hovering effects to suit your needs, but that should get you up and running.
I have a simple form that searches through the 2000+ issues of a 3rd party webcomic. (Easy, it's like xkcd: http://url/number
That form is as easy as possible, is like this:
What number do you want?
User writes a number, clicks ok, and goes on the 3rd party website on a new tab
Then, my form asks a question: "Did you find that issue memorable? Enter the name here, and we will add it to the "best issues" in home page"
When the user will write the name of the issue, it is added to the database (pending moderation by me)
So, I supposed this design is the easiest and convenient that users can find.
Unfortunately, NONE of the users (maybe a 2% behaved correctly) will actually read what I asked. Some of the issues are offline, and gives a 404. On that issues users will write in the textbox a completely wrong title, and correctly capitalized!
It's like if i would name http://xkcd.com/627/ as "The Great Adventures of Jack Smith"
Users are from around all over the country, with different browsers, and have a different cookie.
I cannot believe that my users will not read what I ask, it is a WHITE PAGE with a button that disappears when clicked and a textbox.... easier than that???
Maybe i should put a checkbox with "I acknowledge that this form is for submitting memorable issues, not for fun"? Oh, who will read that?
Or maybe i could enable the textbox only if the user has effectively clicked the link?
Do your users understand your site/service?
I, for one, don't remember (web-)comics by their issue number, but by their content. When asked what xkcd comic number I would like to see, I'd probably input random numbers like 42, 123 or 666 or something.
After you make me guess for a number you ask me if the associated comic is particularly epic, then you ask me to do some data entry for it to put it on some kind of hall of fame. Honestly I do not understand what the logic is behind inserting titles for non existing comics -- are you sure they don't actually land them on the comic page for "The Great Adventures of Jack Smith"? The 2% of your userbase probably noticed the issue in the URL you generated for them, addressed it and typed in the right title. Or, maybe, they are typing the name of the comic they actually wanted to see instead.
There's a simple way to know. Have your mom use it and do not correct her if she makes mistakes. All mistakes she makes are your fault, not hers.
Without having the text of the labels you have put it's harder for us to second guess what's going wrong than it is for you.
Try it!!
You could try parsing the title of the page and obtaining the title yourself
OR you might want to request the username/handle.
Once the user enters the details and clicks SUBMIT, Show a confirmation page ( preview of how the submission will be listed). Make sure to include the username/handle as the person who submitted it (This brings a sense of responsibility to the guy who submits). Remember to keep a back button to allow the user to go back and make the necessary changes ans submit again.
Allow users to create profiles on ur site (they maybe as simple as stackoverflow's profile system. here's mine for example). Unless he is logged-in, submissions posted as anonyomous. Rest same as above.
NOTE: There might be a slim possibility that, U are be being targetted by spam / captcha bots. Hence the random text entries. still. do implement the above. A better UI never hurt anyone. Right??...
I wanted to open up the topic to discuss ways to encourage or incentivize users to fill in information in a user profile on a website, such as skills, location, organization, etc. More information in a user profile can give a website an improved capability for its users to search, network, and collaborate.
Without bugging users to fill in their profiles (ie - via annoying e-mail reminders), what other ways have you come up with to encourage user input?
I have noticed that a simple graphic image (showing percentage complete..some thing like a battery icon on the cell) next to the username ( to the user) with a hover text (your profile is x% complete - click here) works.
I find the Stack Overflow concept of badges or some other kind of reward hook very useful for this kind of thing. You could of course limit access to features also based on information in the profile.
Make filling in this information a benefit for the users. For example, "if you fill in your location, we can filter search results based on that information."
It's all about making the user get perceived benefit from doing an action.
Linking to a privacy policy that is devoid of legalese and doesn't cause the user to navigate away from the forms to fill out their profile usually helps. Additionally, marking any field that will be public with "Viewable to everyone" in addition to marking the rest with "Private" will also help. Whenever possible, make the private fields optional.
E.g for every field, let them expand a container that explains how the data in that field will be used, in plain language.
A quick search will turn up a ton of controversy surrounding Facebook, Google and more regarding privacy. Make sure the form adequately puts out fear fires.
Additionally, limit the number of questions, make sure the tab key works as expected, etc, etc.. but that's all general usability.
Exposing the benefit, in some form of feedback is a really good way to go - show your users that they have gotten something out of it.
Trophies, or some sort of social effect ("45 users have filled in their profile, will you?") are good ideas.
Another option is to show the user a "percentage completed" bar of their profile (like LinkedIn does, called "Profile Completeness"). Many people will feel the need to get that bar up to 100%.
I am developing an issue tracking application in Django, mostly for a learning exercise but also for my own projects - and I am looking into using some AJAX for "enhanced" usability. For example, allowing users to "star" particular issues, which would add them to their watch list. This is implemented in a lot of sites, and is often AJAX - as the URL that the user is viewing doesn't need to change when they click the star.
Now, I am wondering what kind of response to return from my star_unstar view - that detects whether the request is being made via AJAX or not.
At present, if the request is an AJAX request, it returns just the section of HTML that is needed for the star, so I can replace the HTML in the star's parent DIV, so as the star appears "on" or "off", depending on the user's action.
However, I would much rather return some kind of JSON object, as it just seems more "proper", I think. The problem with this method is that the javascript would have to modify the star image's src attribute, the href on it, and the link title also, which seems a lot of work for such a simple feature. I am also looking into in-line commenting in the future, but I want to get a feel for how things "should" be done before I start coding lots of JS.
What is the general consensus when implementing features such as this, not just with Django, but all frameworks that operate in a similar way?
When I work with Ajax my main concern is usually to limit the amount of data I have to send. Ajax applications of this type should be very responsive (invisible if possible).
In the case of toggling a star, I would create the actual on/off states as CSS classes, StarOn and StarOff. The client will download both the off and on star when they first visit the page, which is acceptable considering that the star is a small image. When you want to change the star appearance in the future, you'll only be editing CSS, and won't have to touch the javascript at all.
As for the Ajax, I'd send back and forth one thing -- a JSON variable true/false that says whether or not the request was successful. As soon as the user clicks on the star, I'd change it to the StarOn state and send out the request. 99% of the time Ajax will return true and the user will not even realize that there was some sort of delay in the web request. In the rare case where you get a false back, you'll have to revert the star to StarOff and display an error message to the user.
I don't think your question relates particularly to Django or Python, as you point out at the end.
There's a lot of personal preference in whether you return a blob of HTML to write into the DOM or some serialized data as JSON. There are some practical factors you might want to take into account though.
Advantages of HTML:
- Easy and fast to write straight into the page.
Advantages of JSON:
- Not coupled to the front-end of your application. If you need that functionality anywhere else in the application, it is there ready to go.
My call on it. It's only a relatively trivial amount of HTML to update, and I'd probably go for returning JSON in this case and giving myself the extra flexibility that might be useful down the road.