2

I have an application where i need to check whether the username and password given as input is google's username and password, then show him some custom settings based on that.

I could not check on the internet as in my office, the Gmail keyword is blocked and when I navigate to other sites, they are blocked because of blocked keywords.

Can anyone guide me? Either PHP or Java is acceptable.

Updated Info

http://www.sourcebits.com/geemail/
Just check the AIR Application, they have developed. i was thinking something like this.

Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
Thalaivar
  • 23,282
  • 5
  • 60
  • 71
  • 3
    This is probably not a good idea from a security point of view. Have you considered using OpenID? The user could use Google's OpenID to log in, and your application could react accordingly – Pekka Nov 24 '10 at 10:11
  • 1
    What do you mean by "google's username and password"? Do you mean the user's username and password for Google apps such as Gmail? – Dónal Nov 24 '10 at 10:15
  • Updated the post which might clear a bit more. – Thalaivar Nov 24 '10 at 10:34
  • i routinely access my gmail outside my browser for which i use thunderbird. if you need to do something along the lines of the air application, you are essentially writing a desktop email client. – Kinjal Dixit Nov 24 '10 at 10:42
  • @kinjal: Desktop you say? Now that's something different - the data are not proxied through a third party - but with PHP, that's *very* unlikely - as it's essentially a server-side language (and CLI, yes, but I still have to see a PHP desktop GUI). – Piskvor left the building Nov 24 '10 at 10:55
  • @piskvor: i think i confused and should stay away from the PC for a few hours. :) – Kinjal Dixit Nov 24 '10 at 11:01

4 Answers4

6

"Oh hello, if you only give me your username and password to google's services, and also your SSN, and CC number and PIN, and your birth date, name and address; I need it all but I won't misuse it, honest."

That's what I hear when someone asks me for my name and password, for an e-mail service no less: what do most password-recovery systems use? Oh, right, your e-mail. The access to which you've just shared with an anonymous stranger. On the Internet. But hey, Facebook also asks for the right to ruffle through your e-mails, and they wouldn't be evil, so no problem, right?

Also, your app now needs to store username+password, as it will essentially become the user, as far as Google is concerned. I trust Google not to leak my name and pass; OTOH I absolutely do not trust you not to leak those (either intentionally, or through an outside hack, or an inside disgruntled employee). I do remember a related question about a similar service logging in as you.

@Pekka is right, if you're trying to use the user's access to Google, you should do this using Google's OpenID endpoint, as it's explicitly made for that situation, yet doesn't give you the control over the user's account. (I'm assuming you are not trying to phish the username and password)

Community
  • 1
  • 1
Piskvor left the building
  • 91,498
  • 46
  • 177
  • 222
  • I think either i was not clear about what i intend to do, should have thrown an example. just check down my updated post. – Thalaivar Nov 24 '10 at 10:35
  • 1
    @Vinothbabu: No, it's clear all right. They seem to be saying "give us/our app your GMail name and password, and we will only use it for showing you an awesome version of GMail, really, trust us". The problem here isn't computational, it's trust: do you trust a website not to abuse this access? Personally, I wouldn't - if only for the fact that your name+pass will be ultimately stored in someone else's hands. Maybe they won't abuse it, but what about a disgruntled employee? Or their db gets hacked? In other words, I don't trust them *enough*. – Piskvor left the building Nov 24 '10 at 10:41
  • never attribute to malice what can be attributed to stupidity, and never attribute anything to stupidity without first vigorously checking for semantic gaps. – Kinjal Dixit Nov 24 '10 at 10:46
  • @kinjal: I'm not accusing anyone of malice by saying I don't trust them (please don't conflate "trust" and "like", those are independent). I'm stating a fact. Would you entrust your usernames and passwords to any random stranger? The stranger *may* be honest, but just from a webpage, there's no way to make sure. – Piskvor left the building Nov 24 '10 at 10:50
  • @Piskvor: i feel you, but questioning the intent/motives will take us no where. What if someone asked a question on how to format a hard disk or delete all files from a folder? Do we have to first establish that the intent is bonafide before answering the question. (the previous comment light hearted, and i am not able to edit it anymore to put a smiley at the end). – Kinjal Dixit Nov 24 '10 at 10:51
  • The topic is moving over trust which solely lies on the end user my dear friends. Would you trust paypal for your online transaction some may and some may not. I was just going through on how they would have, i doubt without an server side stuffs they could have brought up this. – Thalaivar Nov 24 '10 at 10:53
  • Ah, all right - you're writing a *desktop* app! Well, the mention of PHP confused me - I thought you intended do make some sort of web-proxy for it. That makes much more sense then (and makes most of our discussion moot). Sorry for the misunderstanding. – Piskvor left the building Nov 24 '10 at 19:07
3

you can use peruse the google documentation for this to get more information about the user, provides he/she grants permission to your site. just like how stackoverflow openid works.

http://code.google.com/apis/accounts/docs/OpenID.html

you should also check: http://code.google.com/p/openid-selector/

Kinjal Dixit
  • 7,777
  • 2
  • 59
  • 68
2

OpenID is a safe, faster, and easier way to log in to web sites. :D use open id ...

there is many lib in this address http://wiki.openid.net/w/page/12995176/Libraries

Mohammad Efazati
  • 4,812
  • 2
  • 35
  • 50
2

Use OpenID or OAuth if you want to authenticate to Google's Services.

Buhake Sindi
  • 87,898
  • 29
  • 167
  • 228