I have built a site and have several social networks to promote it, and sometimes I have giveways to people which I normally have through facebook. The giveaways normally require that the person subscribe to something (as a counterpart of receiving the giveaway or participating on trying to win it), but facebook and other sites just are bad for these kind of things, specially proving that you subscribed to anything.
So here's my thought:
Use a fillout template (like a HTML FORM)
person login with a FACEBOOK Account
Based on that Facebook account, person subscribes to
newsletter, likes a page, whatever, but everything done through that
FORM-like thing, logged in, one step to participate.
In your experience, is this even possible? with what? CSS, HTML, JSQUERY...
This time I'm opened to anything you can guide me, I'm tired of trying to work
giveways through social networking site's GUIs is just annoying...
Thanks for all the help you can provide.
Alban
Sounds like you want Oauth and OpenId. It's not particularly easy to set up, but it's very effective. If you sign into stackoverflow using google you're probably using it.
According to wikipedia facebook no longer support it, using facebook connect instead, but almost everything else does.
Related
I have a very confusing problem.
I have a page which only allow paid users to view it. So if the user is not valid I use a pop up with grey backgroud to block users to view the page however there is a potential flaw with this and if a user is clever he can find a workaround and by using the inspect element bypass the popup. Another solution which comes to my mind is to redirect the user to another page instead of pop up like:
window.location = "http://www.example.com";
However there is a potential problem with this or may be I am wrong on this:
I think this way google bots wont be able to crawl that page since redirection happens however in the first approach google will definitely be able to crawl the page.
Now my question is if I use the first approach is there anyway to stop user from manipulating the popup or is there anyway I can distinguish if a user is browsing the page or google?
Also if I use the second approach will google bot be able to crawl the page?
You can't implement a paid block or any types of truly secure/working blocking on the frontend. I would suggest prevent accessing to that said page on the backend.
There's no real clean and 100% working way to this on the frontend. The user can always bypass.
For google, it will be able to crawl the page since the content is still accessible via the rendered html, as it does not care how the page is shown. It gets access to the content anyway, just like you would by fetching the html via a get request without a browser.
You could indeed just redirect, but still do it on the backend not the frontend.
Your current solution does not make the page private - as you rightly point anyone can manipulate the page using the dev tools, and crawlers can read the whole source anyway. Using server-side scripts to block access, and/or vary the content based on an authorisation token is the only way to secure it properly and ensure that only your legitimate paying users get privileged access.
You state a concern about the inability for Google (and other search engines, I assume) to crawl the page if you employ better security. But your logic is flawed: If you make it so that a google bot can still crawl the page, then by definition it must be readable without authorisation. Anyone could view it in the google cache, and parts of its content could show up in google searches. This means it isn't private. Once that's the case, then what are your users paying for, exactly?
What you might realistically want to do is have a cut-down version of the page that is displayed when the user is not authorised, containing enough information for search engines to get an idea of the overall content, and for visitors to be tempted into paying for the rest. Then if the user logs in, the server recognises that and displays the rest of the content as well when the page refreshes. That appears to be roughly what paid-content news sites do, for instance.
I am making a personal (resume type) website. I was hoping to retrieve all of the data from my facebook page and display it on the about page using the Graph API.
The issue is, it seems like a user always has to give credentials to get an authorization token. I don't want to require people to log into facebook just to view my page. I also don't want to login everyone using my credentials (which would mean they would be stored in JavaScript). Does anyone see a way around this?
I looked into the creating a "page" and using the "page access token" instead. Then I could get the page access token using my userid stored in JavaScript (in my opinion much better than username and password). Is there a problem doing it this way?
I would prefer to retrieve this data directly from my account and not have to make a separate "page." Any and all information is appreciated. Thanks for your time.
This appears to be banned in Facebook's Terms of Service:
Safety
We do our best to keep Facebook safe, but we cannot guarantee it. We need your help to keep Facebook safe, which includes the following commitments by you:
You will not post unauthorized commercial communications (such as spam) on Facebook.
You will not collect users' content or information, or otherwise access Facebook, using automated means (such as harvesting bots, robots, spiders, or scrapers) without our prior permission.
You will not engage in unlawful multi-level marketing, such as a pyramid scheme, on Facebook.
You will not upload viruses or other malicious code.
You will not solicit login information or access an account belonging to someone else.
You will not bully, intimidate, or harass any user.
You will not post content that: is hate speech, threatening, or pornographic; incites 9. violence; or contains nudity or graphic or gratuitous violence.
You will not develop or operate a third-party application containing alcohol-related, dating or other mature content (including advertisements) without appropriate age-based restrictions.
You will follow our Promotions Guidelines and all applicable laws if you publicize or offer any contest, giveaway, or sweepstakes (“promotion”) on Facebook.
You will not use Facebook to do anything unlawful, misleading, malicious, or discriminatory.
You will not do anything that could disable, overburden, or impair the proper working or appearance of Facebook, such as a denial of service attack or interference with page rendering or other Facebook functionality.
You will not facilitate or encourage any violations of this Statement or our policies.
Sorry to be a downer, but I don't think that page scraping is the best way to go.
Say, a link to a person is sent to a user via email. If the person is already logged into the webpage in his/her browser, clicking on the link takes him/her to the page. However, if he/she is not logged in, he/she should be asked to login in order to access the page. Is there a way to achieve the above functionality using jquery, javascript?
Yes. Build a back-end authentication system, using AJAX and whatever your server-side language is.
From there, develop a hypermedia-style of content-system, and a modular, "widget"-based application delivery model.
Within your hypermedia responses to login (plus passing whatever relevant path information was gained from the e-mail), either redirect the page to a new page (based on the linked response from the server), or download the widgets requested from the server (for whatever application you're displaying media in), and then stream in AJAX content (again, from a URL dictated by the server-response).
This is about as close as you're going to get to security, in terms of delivering things to the client, in real-time, with authentication.
If you were to load the reports/gallery/game/whatever, and put a div over it, and ask for users to log in, then smart users can just kill the div.
If you include the content, or include the application components (JS files), or even include the links to the JS files which will request and display the content, then clever people are again going to disassemble that, in 20 seconds, flat.
The only way I can see to do this is to have a common request-point, to touch the server, and conditionally load your application, based on "next-steps" URLs, passed to the client, based on successful authorization and/or successfully completing whatever the previous step was, plus doing authentication of some form on each request (REST-based tokens+nonces, or otherwise)...
This would keep the content (and any application-structure which might have vulnerabilities) from the client, until you can guarantee that the client has been properly authorized, and the entire application is running inside of multiple enclosed/sandboxed modules, with no direct access to one another, and only instance-based access to a shared-library.
Is it worth the work?
Who knows.
Are we talking about a NORAD nuclear-launch iPhone app, which must run in JavaScript?
Then no, engineering this whole thing for the next six months isn't overboard.
And again, all of this security falls over as soon as one person leaves themselves logged-in, and leaves their phone on the table (biometric authentication as well, then?).
Are we talking about a gallery or discount-offers that you want to prevent people to log into, so you know that only the invited people are using them?
Well, then an 18-month project to engineer, develop, debug and deploy a system like this is probably going to be overkill.
In this case, perhaps you can just do your best to prevent the average person from stealing your content or using your cut-prices, and accept that people who take the time to dig into and reverse-engineer everything are going to find a way to get what they want, 95 times out of 100.
In that case, perhaps just putting a login div overtop of the page IS what you're going to be looking for...
If you're dealing with, say a company back-end, or with company fiscals or end-user, private-data, or anything of the sort, then aside from meeting legal requirements for collection/display/storage, how much extra work you put into the security of the system depends on how much your company's willing to pay to do it.
If it makes you feel better, there are companies out there that pay $60,000-$150,000 a year, to use JS tracking/testing programs from Adobe. Those programs sit right there, on the webpage, most of the time, for anybody to see, as long as you know where to look.
So this isn't exactly an unknown problem.
Yes it is. By authenticating (login) you can store a "loggedIn" cookie which you have to delete by session end (logout or closing the browser). You can use that cookie to check if somebody is logged in or not. If not logged in, than you can display the login page and send the login request with ajax. Btw it is not a good practice to use hybrid applications like that. It is better to use SPA-s with REST service, or implement this on server side.
I am trying to create a firefox extension to detect if someone successfully logs into a site, but am having a little difficulty determining an algorithm to do this.
My thoughts right now are to use javascript to accomplish this and to firstly check to make sure the user is on a page with a login, for all intensive purposes a password field. Then after a login attempt has occurred, I would check to see if it is successful by looking to see if a password field is still on the page.
Another idea would be to compare the url before and after the login and see if they are different, yet within the same domain. This however, has drawbacks for sites like facebook, for which the login and the landing page are the same.
Does anyone have any other ideas on how I might make this detection?
Thanks in advance!
You pretty much can't make a generalized detection algorithm that would work on each page. As you yourself mentioned, different pages have different schemes.
Even in the scheme where the login and landing page are different, how would you know whether the post-login page displays an error or notifies somebody of a successful login?
The first method you mention actually has some merit and might really work for most of the sites, but again there is a good chance you will run into problems when we talk about logging in using FB authentication or Google Accounts authentication, as there are multiple redirects, and also a password input may never appear (in case I am already logged in to Google Accounts, then jut choosing Google as my ID provider logs me in to StackOverflow).
If you could consider the above mentioned case and come up with a workaround (checking redirects for specific providers.. there are not many of them, so you could cover most of the cases), then yes, your first solution combined with this could provide a workable method.
I like the idea of OpenID, I really do. But few of my target users have even heard of it - yet. If I want to offer OpenID as an option, my only choice would seem to come down to offering BOTH email/password authentication AND OpenID.
I've seen several sites that use this combination and the idea seems unappealing to put it mildly. Placing both options on the same screen is distracting and pointless if only 10% of users will even care about OpenID.
So I'm wondering, how could I offer a single user interface that supports BOTH OpenID and email/password for authentication and account creation?
One possibility I've been considering is to use a single OpenID/email field that can detect whether an email or OpenID was used and then dynamically adjust the interface accordingly.
For example, an account creation page might start off with a single field labelled "email" with some unobtrusive text along the lines of "we support OpenID". If a user enters a url, then the interface switches to an OpenID account creation page (via JavaScript). If an email address is entered, nothing happens.
What's the best method you've seen for hiding OpenID from the average user, but at the same time letting tech-savvy users know that your site supports it?
I think the way Uservoice combines username+password with OpenID is elegant.
That said, I disagree with the argument of not using OpenID merely because few people have heard of it. If you offer a few login buttons like "Login with Google" and "Login with Yahoo" alongside your "or, create a new username and password for yourself", then you don't even have to mention OpenID, and yet most users will likely pick the more convenient (OpenID) option without even realizing what they're using (and that's good!)
Decided to do some checking around on my own. Turns out there's a much better idea out there. The term seems to be 'OpenID selector'.
There's a free JavaScript library called JavaScript OpenID selector that makes it easy to create this sort of thing:
alt text http://img9.imageshack.us/img9/1940/step1c.png
This article explains the main problem and the solution:
One of the key results of Yahoo's OpenID usability study was that users did not understand OpenID and what its logo stands for. Instead, Yahoo promoted the idea of giving users a sign-in button that simply said "Sign In with a Yahoo! ID" (though Chris Messina argues that this could be detrimental to OpenID in the long run).Google and its partners are taking a similar route and are basically bypassing any mention of OpenID itself in favor of a simple message saying "Sign in with a Google Account."
There's even a sample Rails application that rolls authlogic, openid, and the selector into a single package so you can see how everything fits together.
See how SO here does it. That's a good a example, I like your idea of adapting the system by entered email as well, this is a trick facebook uses to send out facebook invitations to other people in your address book.
Would something like the following work?
Link to Login Page.
Now this site is running DNN and obviously it could be redesigned to be friendlier for the users. But the key here is that the standard way to sign-in is presented as the default sign-in.
I would probably redesign that site's interface to put LiveID and OpenID in a border labeled with Alternative Login Methods (along with a button for more help on how to use them) as well as change the buttons to read Sign In Using LiveID and Sign in Using OpenID.