Is there any way to use some paypal api for validation of username in paypal?
Google didn't give much :( and using such method isn't comfortable, cause there are too many requested parameters(for example, i know user's email, but i don't even want to know his adress,etc.).
PayPal doesn't provide such an API and for a very good reason.
Remember - it's being constantly under a lot of pressure from scammers around the world that are trying to steal other people's money. Just imagine the phishing power one might get by being able to pre-validate the email addresses to see if they really are current PayPal users and then crafting a targetted email attack on them...
Such an API (to see if a random email address is registered with a PayPal account holder) does not and never will exist for security reasons. With possibly one exception - "trusted partners", where PayPal partners up with a big and established entity and allows special API permissions (based on secure credentials), but this is not something a mere mortal could ever hope for.
Furthermore, if a workaround is discovered that allows to do just that - rest assured PayPal will patch that hole ASAP to avoid security breach.
I received an e-mail from Facebook that i need to include a privacy policy in my Facebook tab. I thought privacy policy's were only needed in Facebook Apps.
Were can i find an example of a privacy policy?
Simply put, the reason for Facebook's strict requirements are mostly because of them wanting to demonstrate that they do everything to educate their users "we told the user to have a privacy policy". Therefore you receiving that email may not necessarily be related to you doing anything related to privacy.
In theory it's still possible to gather data from a tab/page with input forms.
iubenda has been specialising in this kind of problem with a dedicated privacy policy generator for Facebook apps and a hosting service for privacy policies built in: http://iubenda.com/facebook/
There's also a basic free version to be had for the general privacy policy here http://iubenda.com (edit: I haven't pointed out that the free version only works for web policies, as commented on by one user)
(disclosure: I work with the iubenda team to keep this being the best possible tool out there)
I would recommending using http://termsfeed.com/free/privacy-policy-generator
in preference to http://www.freeprivacypolicy.com/free-privacy-policy-generator.php since the latter has a terms of use that includes:
Permission is granted ... for the sole purpose of placing an order with FreePrivacyPolicy.com or purchasing FreePrivacyPolicy.com products. Any other use, ... is strictly prohibited, unless authorized by FreePrivacyPolicy.com.
Sorry I couldn't send a link to their terms of use, it appeared as a javascript popup, at the end of their wizard questionaire.
http://www.generateprivacypolicy.com/
I use this to create a privacy policy for just several seconds.
I got the same mail aswell and I don't really understand why. I used this one to create it: http://www.freeprivacypolicy.com/free-privacy-policy-generator.php
Do you gather any data (forms, etc.) from that particular tab? They may simply have changed the requirements.
You should try to re-write any privacy policy depending the type of data you gather (or not).
You can also use the following from Termsfeed (free generator): http://termsfeed.com/free/privacy-policy-generator
Simple Facebook features like Page Plugin (which used to be called Tabs) do not require a Privacy Policy or TOS. The essential fact I found when when trying to work this out was in the FAQ. You don't need an "app," or even a developer account. https://developers.facebook.com/docs/plugins/faqs says it. That means you don't need an app Privacy Policy or TOS.
A problem arises when you are logged in as a developer and click "Get code" in the wizard at https://developers.facebook.com/docs/plugins/page-plugin/. It gives you the developer version of the javascript SDK. It has the line js.src = 'https://connect.facebook.net/en_US/sdk.js#xfbml=1&version=v2.12&appId=...&autoLogAppEvents=1', with your most recent appId filled in.
The workaround is to log out of Facebook before using the wizard. Then you will get the correct code which does not require Privacy/TOS: js.src = 'https://connect.facebook.net/en_US/sdk.js#xfbml=1&version=v2.12'.
I found an excellent one (which even generates and hosts your privacy policy) here by privatychoice.org
We want to streamline the user registration and login process. The goal is to reduce the time and effort for users to register and login to our site.
At the same time, we don't want to overwhelm users with choices. We don't like how some web sites present registration/login options via multiple channels (e.g., Facebook, Twitter).
What are the pros/cons of each of these systems? Which do you use, and what are your main gripes?
Offer all of them, don't take the time to ask "why?".
It's always worth it to get users on board.
The biggest (IMO) pro is that you are no longer storing passwords in your db. Leveraging one of those other site's authentication service relieves you of this. It doesn't relieve you of having a secure design. I'm also not sure that your average end user really cares. If your service is highly aligned with one of those services, maybe. However, if you are not targetting those end-users, then probably not.
Rob Conery did a recent write up of his experience with OpenId. This might be a good read:
http://blog.wekeroad.com/thoughts/open-id-is-a-party-that-happened
Hope this helps.
Bob
Well, yes, it does all depend on your user audience.
In any case, I would say that Facebook Connect is probably your best bet due to the sheer number of people using Facebook. Still, as far as I've noticed, it's not really "professional" websites that use Facebook Connect, mostly forums and unofficial (but popular) news blogs.
Many "professional" websites (catering to... well, professionals) will use a normal Register/Login rather than Twitter, Facebook, or OpenID. Still, a professional website would likely need a more professional solution, so I would suggest OpenID, which also supports websites such as Yahoo! Mail and developer communities (such as Stack Overflow!). You can see the full list of sites here.
In all honesty, I don't really think that using a Twitter login would be very efficient. Think of it this way: for one, I've noticed (but I could be wrong) that Twitter is mainly used by the small hobbyist or the people who use it to give updates on things they're doing or making (and sometimes just the people who want to be in on the times). So unless your website is aimed at these type of people, it wouldn't really be useful. On top of that, I don't know of many people who particularly like it, partially because of its over-popularity. Still, it could be the same way with Facebook, but this is all subjective, so if you really want to pick Twitter, go for it.
Anyway, that's my take on things. I don't personally use these systems on websites I've built, but I know how they work.
For one, when you log in using any of these for the first time, they take the user to a new page or open a popup window asking them to confirm if they want to connect their [Whatever] account to your [Website Name]. After that, it's a bit easier to use just because they don't have to keep repeating the process unless they disallow your website on their service.
With OpenID, you have to log in to your OpenID-enabled webpage using http://myusername.myopenid.com/ or myusername.myopenid.com. If they don't choose to remember their password, this can become a bit tedious to type in every time.
With Facebook Connect, it usually automatically connects all of their information to the website, including full name and profile picture (meaning that if they have a profile picture of that snazzy tattoo on their inner thigh, other users will be able to see that).
Finally, as far as I can see, Twitter doesn't do much other than connect whatever name you had on your profile page (if it's "John Doe" or "Weiner Schnitzel", it'll show on your website) and your profile picture, just like Facebook.
To finish up, those are pretty much all the pros and cons that I can tell about the services. Good luck!
What is your target group?
If you want that many normal people uses your application than use Facebook.
If there are many coder / blogger / internet junkies than use Twitter.
If you have a lot of open source guys than OpenID will do the job.
If i'm is not wrong, previously there is a website providing kinda service about providing login platform to allow user connect to your site. Of course it is not free and i was abandon it because of high annual fees and mind change after research being done.
While you using their service to growing your business or website, you can save their time it's true. but honestly, will they really care on how long time taken to connect their facebook with your website either register as a new member in your website. While you can give confidence to you client, they do. they willing to spent few minute to fill up simple information to make an account for them self if they felt they worth to spent the minute to get service from your website.
Totally agreed to what rcravens said, if they connect through third party website, means you are gonna giving you user information to that website. For example, to archive FACEBOOK CONNECT you will need to create an application for them to trust them you only can get authority to access. while they accept and login to your site, it is good for FREE advertise because while they connect, can use their account as medium to post your information to public. BUT mostly site will sell their information gather or share them in any way to some organization who need them for decision.
My point is, how many people using your site and mostly who is using, what characteristic of your site user and so on... everything is no more under your control !!!
Perhaps, you may use it but what if their service shut down few hour for maintainance...
I'd recommend using something like RPXNow (https://rpxnow.com/) or Gigya (http://www.gigya.com/) as an intermediary to the various authentication providers. Facebook and Twitter are notorious for always changing their APIs. It is a pain to keep up with them. These services give you a simple abstraction layer, so that you don't need to change anything on your end when the providers change their APIs.
i like facebook but..
facebook is block in some country.
open id is not famous.
twitter is famous and simple.
so use twitter is the best :)
Use OpenID as it is a standard that is also integrated into many Mail Accounts, like Google or Yahoo. You never know how long Facebook will stay around and therefore it's better to have something people just don't throw away (there Mail address). If you make a nice selection screen (e.g. stackoverflow), the people don't even know that they're using OpenID. If you just want to get authorized Comments, picture uploads for twitter or fb, a game connected with social features don't use it.
Facebook Connect is very usable for one time comments or stuff like this. If you want to store your own data about the user (e.g. blog service, saas), not dependend on "social networks" don't use it.
Twitter Login makes only sense if you connect your service with Twitter, otherwise forget about it.
I would use a hidden OpenID approach.
Facebook is great for keeping tabs on family and friends. Beyond that I, personally, wouldn't use it in support of any other app. It's just not bullet-proof enough from a security/malware standpoint. There is too great a chance someone could have issues of that sort with Facebook and attribute it to your site, whether reasonably so or not.
I like OpenID. Not thrilled with the notion of hitching my wagon to any of the social networking sites/services at all.
Is this a technical or commercial question?
The answer to my mind is it depends what you want to do with the data.
If you just want to provide a service to a broad list of people then the answer has to be to gun for openness, not proprietary - particularly since the open standard is supported elsewhere, Gmail, Yahoo et al.
However, if you want to demographically profile that database at some point to offer targeted services, then you need to understand the questions you're likely to require answered and whether a third party method is going to enable that or not.
Jeff Lindsay, who coined the term 'webhook', said that the difference between webhook and http callback is that webhooks are user-defined. I think I understand what he meant, but I was thinking about it and I asked myself, can webhooks be effectively used by regular users (I mean: non-developers)?
Usually people don't have a clue how the internet works, they don't know what http is, terms like URL, callback, or request-response don't say anything to them. I've heard that many people do not know the difference between a web browser and a web site, they think that internet really starts at google.com and they type in all urls in the google search box... I mean, what's the use of webhooks when you're not a developer?
Do you think services like AlertGrid make sense? It's a webhook consumer that you can configure to dispatch alerts (SMS, phone, email) either when the callback is NOT received in x amount of time, or when the received data meets user-defined condition, plus it does some data visualization. We wanted it to make webhooks usable for non-developers. But still it requires an initial integration by someone who at least knows how to configure the source to send the webhook events. In many cases it only takes pasting an url to a textbox, but it seems to be beyond the skills of a typical user.
So, are the webhook doomed to be used by software developers only, or is there a chance that millions of Facebook or Twitter users will start making use of them somehow?
I think that something implemented using Webhooks can be made very user friendly.
Suppose Stack Exchange allowed users to define a webhook that would be notified whenever you earned a badge. You could supply a custom URL, or there could be simple buttons to click that would set it up for your Facebook or Twitter account. It could be as simple as the Facebook Like button.
YES I think this is a great idea. It's actually something I designed in my head a couple months ago and didn't think the product existed.
Webhooks are extremely powerful and having a 'service bus' aggregate/manage/dispatch these callbacks is extremely compelling to me.
I think that we are a long way from the general public consuming webhooks in any sort of meaningful way but I don't see why not. I remember when RSS was a 'developer' only technology.
Thanks for the link. I'll be digging in more this weekend.
If this question has already been asked, please comment so I can remove it.
I'm aware of the advantages of email verification, especially in regard to spamming (which could easily kill me since most of the functionality is in posting comments).
I'm contemplating the removal of email account verification for the application I'm currently building. This is for numerous reasons:
I've noticed other apps/websites
simply don't implement it.
It's far more user friendly then to
skew the user over to their email.
Since the application is moderate in scale and functionality, revisits are short-lived, some users may be inquisitive about it as to sign up, but some might feel it's an overkill to actually go through email verification.
App is not celebrated as to compel visitors to take effort, sign up and verify.
I know I'm getting into the gust of it, and while I'm writing this visitors could've verified their account for the gazillionth time; however, would you agree that for some moderately scaled applications an account verification might deter a casual visitor?
What measures do you personally prefer to undertake?
Why not use some form of federated ID like OpenID and such?
Verification is good if you plan to send email to them on a regular basis. Otherwise if it's just a casual site, you will probably need to offer something compelling to get them to register and provide you a valid email address.
Do you have something compelling?