I know that as of right now - we cant get this information user's
email address based on authsub. This is fine but I'm sure many other
users not just myself would like to know why as well. if there was an
answer can some one point me to it? Besides the "google doesn't...", I
am asking: Why?
And if it is a security issue - is it too hard to give us a user hash
(MD5 maybe) using the username as the data and the appid as the salt?
Or better still so that we can't rev-eng the data, the internal google
user_id and the app_id as salt - same MD5, or some one way encryption
- something. From what I understand,
this doesn't take any storage or large memory cycles to do this. Just
return it to us - you don't even have to store it.
THE BIG QUESTION
How do we tie returning user's to a gmail account? I have plenty of
hacks to do this with (user calendar, google base) - but these are
extra steps, that aren't really needed for something so simple.
We are all internet users -
Google, Hotmail, Yahoo, AIM hold the keys to ridding the internet of
the [register] step for websites - Yahoo and AIM have already taken
the initiative to allow their users to login to authorized websites
and return a unique id,
Live is working on theirs now (not passport) - and they provide us
with ways to tie their user - back to our accounts
If this optional parameter equals '1', the Yahoo! login server
includes an unique identifier for a particular user in your endpoint
URL. With the userhash you can identify a returning user or even build
an application that requires sign in without having to build the
authentication part yourself. The identifier is bound to a specific
appid.
Validates the Authentication Token issued and returns user's loginId
and displayName along with last authentication time stamp. The getInfo
method can be invoked in a browser either as a redirect or as a JSON/
JSONP call from the browser.
I mean - its right there - this is all we are asking for.
Hi - thanks for your email. This request has come up several times
before, and we understand there is demand for it. Could you give a bit
more background to your use case? A pointer to your website would be
easiest if your site is already public.
Vince.
On Dec 13, 7:51 pm, maufau <mau...@gmail.com> wrote:
> I know that as of right now - we cant get this information user's
> email address based on authsub. This is fine but I'm sure many other
> users not just myself would like to know why as well. if there was an
> answer can some one point me to it? Besides the "google doesn't...", I
> am asking: Why?
> And if it is a security issue - is it too hard to give us a user hash
> (MD5 maybe) using the username as the data and the appid as the salt?
> Or better still so that we can't rev-eng the data, the internal google
> user_id and the app_id as salt - same MD5, or some one way encryption
> - something. From what I understand,
> this doesn't take any storage or large memory cycles to do this. Just
> return it to us - you don't even have to store it.
> THE BIG QUESTION
> How do we tie returning user's to a gmail account? I have plenty of
> hacks to do this with (user calendar, google base) - but these are
> extra steps, that aren't really needed for something so simple.
> We are all internet users -
> Google, Hotmail, Yahoo, AIM hold the keys to ridding the internet of
> the [register] step for websites - Yahoo and AIM have already taken
> the initiative to allow their users to login to authorized websites
> and return a unique id,
> Live is working on theirs now (not passport) - and they provide us
> with ways to tie their user - back to our accounts
> If this optional parameter equals '1', the Yahoo! login server
> includes an unique identifier for a particular user in your endpoint
> URL. With the userhash you can identify a returning user or even build
> an application that requires sign in without having to build the
> authentication part yourself. The identifier is bound to a specific
> appid.
> Validates the Authentication Token issued and returns user's loginId
> and displayName along with last authentication time stamp. The getInfo
> method can be invoked in a browser either as a redirect or as a JSON/
> JSONP call from the browser.
> I mean - its right there - this is all we are asking for.
I'd love to see it to for the exact same reasons that maufau suggests
and for the same reasons that Yahoo provides this service. Basically,
we want to use it like OpenID.
I don't want users to have to remember another userid and password for
my site, so I want them to be able to authenticate to Yahoo/MSN/Google/
OpenID/Facebook, who will then pass back to my site a consistent and
unique anonymous user-hash that I can identify that user when they
come back to my site and sign in again.
On Dec 14, 10:15 am, Vince Wu <v...@google.com> wrote:
> Hi - thanks for your email. This request has come up several times
> before, and we understand there is demand for it. Could you give a bit
> more background to your use case? A pointer to your website would be
> easiest if your site is already public.
> Vince.
> On Dec 13, 7:51 pm, maufau <mau...@gmail.com> wrote:
> > I know that as of right now - we cant get this information user's
> > email address based on authsub. This is fine but I'm sure many other
> > users not just myself would like to know why as well. if there was an
> > answer can some one point me to it? Besides the "google doesn't...", I
> > am asking: Why?
> > And if it is a security issue - is it too hard to give us a user hash
> > (MD5 maybe) using the username as the data and the appid as the salt?
> > Or better still so that we can't rev-eng the data, the internal google
> > user_id and the app_id as salt - same MD5, or some one way encryption
> > - something. From what I understand,
> > this doesn't take any storage or large memory cycles to do this. Just
> > return it to us - you don't even have to store it.
> > THE BIG QUESTION
> > How do we tie returning user's to a gmail account? I have plenty of
> > hacks to do this with (user calendar, google base) - but these are
> > extra steps, that aren't really needed for something so simple.
> > We are all internet users -
> > Google, Hotmail, Yahoo, AIM hold the keys to ridding the internet of
> > the [register] step for websites - Yahoo and AIM have already taken
> > the initiative to allow their users to login to authorized websites
> > and return a unique id,
> > Live is working on theirs now (not passport) - and they provide us
> > with ways to tie their user - back to our accounts
> > If this optional parameter equals '1', the Yahoo! login server
> > includes an unique identifier for a particular user in your endpoint
> > URL. With the userhash you can identify a returning user or even build
> > an application that requires sign in without having to build the
> > authentication part yourself. The identifier is bound to a specific
> > appid.
> > Validates the Authentication Token issued and returns user's loginId
> > and displayName along with last authentication time stamp. The getInfo
> > method can be invoked in a browser either as a redirect or as a JSON/
> > JSONP call from the browser.
> > I mean - its right there - this is all we are asking for.
> I'd love to see it to for the exact same reasons that maufau suggests
> and for the same reasons that Yahoo provides this service. Basically,
> we want to use it like OpenID.
> I don't want users to have to remember another userid and password for
> my site, so I want them to be able to authenticate to Yahoo/MSN/Google/
> OpenID/Facebook, who will then pass back to my site a consistent and
> unique anonymous user-hash that I can identify that user when they
> come back to my site and sign in again.
> On Dec 14, 10:15 am, Vince Wu <v...@google.com> wrote:
> > Hi - thanks for your email. This request has come up several times
> > before, and we understand there is demand for it. Could you give a bit
> > more background to your use case? A pointer to your website would be
> > easiest if your site is already public.
> > Vince.
> > On Dec 13, 7:51 pm, maufau <mau...@gmail.com> wrote:
> > > I know that as of right now - we cant get this information user's
> > > email address based on authsub. This is fine but I'm sure many other
> > > users not just myself would like to know why as well. if there was an
> > > answer can some one point me to it? Besides the "google doesn't...", I
> > > am asking: Why?
> > > And if it is a security issue - is it too hard to give us a user hash
> > > (MD5 maybe) using the username as the data and the appid as the salt?
> > > Or better still so that we can't rev-eng the data, the internal google
> > > user_id and the app_id as salt - same MD5, or some one way encryption
> > > - something. From what I understand,
> > > this doesn't take any storage or large memory cycles to do this. Just
> > > return it to us - you don't even have to store it.
> > > THE BIG QUESTION
> > > How do we tie returning user's to a gmail account? I have plenty of
> > > hacks to do this with (user calendar, google base) - but these are
> > > extra steps, that aren't really needed for something so simple.
> > > We are all internet users -
> > > Google, Hotmail, Yahoo, AIM hold the keys to ridding the internet of
> > > the [register] step for websites - Yahoo and AIM have already taken
> > > the initiative to allow their users to login to authorized websites
> > > and return a unique id,
> > > Live is working on theirs now (not passport) - and they provide us
> > > with ways to tie their user - back to our accounts
> > > If this optional parameter equals '1', the Yahoo! login server
> > > includes an unique identifier for a particular user in your endpoint
> > > URL. With the userhash you can identify a returning user or even build
> > > an application that requires sign in without having to build the
> > > authentication part yourself. The identifier is bound to a specific
> > > appid.
> > > Validates the Authentication Token issued and returns user's loginId
> > > and displayName along with last authentication time stamp. The getInfo
> > > method can be invoked in a browser either as a redirect or as a JSON/
> > > JSONP call from the browser.
> > > I mean - its right there - this is all we are asking for.
> On Dec 18, 3:21 pm, chrisff <chris.fi...@gmail.com> wrote:
> > I'd love to see it to for the exact same reasons that maufau suggests
> > and for the same reasons that Yahoo provides this service. Basically,
> > we want to use it like OpenID.
> > I don't want users to have to remember another userid and password for
> > my site, so I want them to be able to authenticate to Yahoo/MSN/Google/
> > OpenID/Facebook, who will then pass back to my site a consistent and
> > unique anonymous user-hash that I can identify that user when they
> > come back to my site and sign in again.
> > On Dec 14, 10:15 am, Vince Wu <v...@google.com> wrote:
> > > Hi - thanks for your email. This request has come up several times
> > > before, and we understand there is demand for it. Could you give a bit
> > > more background to your use case? A pointer to your website would be
> > > easiest if your site is already public.
> > > Vince.
> > > On Dec 13, 7:51 pm, maufau <mau...@gmail.com> wrote:
> > > > I know that as of right now - we cant get this information user's
> > > > email address based on authsub. This is fine but I'm sure many other
> > > > users not just myself would like to know why as well. if there was an
> > > > answer can some one point me to it? Besides the "google doesn't...", I
> > > > am asking: Why?
> > > > And if it is a security issue - is it too hard to give us a user hash
> > > > (MD5 maybe) using the username as the data and the appid as the salt?
> > > > Or better still so that we can't rev-eng the data, the internal google
> > > > user_id and the app_id as salt - same MD5, or some one way encryption
> > > > - something. From what I understand,
> > > > this doesn't take any storage or large memory cycles to do this. Just
> > > > return it to us - you don't even have to store it.
> > > > THE BIG QUESTION
> > > > How do we tie returning user's to a gmail account? I have plenty of
> > > > hacks to do this with (user calendar, google base) - but these are
> > > > extra steps, that aren't really needed for something so simple.
> > > > We are all internet users -
> > > > Google, Hotmail, Yahoo, AIM hold the keys to ridding the internet of
> > > > the [register] step for websites - Yahoo and AIM have already taken
> > > > the initiative to allow their users to login to authorized websites
> > > > and return a unique id,
> > > > Live is working on theirs now (not passport) - and they provide us
> > > > with ways to tie their user - back to our accounts
> > > > If this optional parameter equals '1', the Yahoo! login server
> > > > includes an unique identifier for a particular user in your endpoint
> > > > URL. With the userhash you can identify a returning user or even build
> > > > an application that requires sign in without having to build the
> > > > authentication part yourself. The identifier is bound to a specific
> > > > appid.
> > > > Validates the Authentication Token issued and returns user's loginId
> > > > and displayName along with last authentication time stamp. The getInfo
> > > > method can be invoked in a browser either as a redirect or as a JSON/
> > > > JSONP call from the browser.
> > > > I mean - its right there - this is all we are asking for.
I'd love to show the use case for this - however this is a feature of
my companies (as of now) private application.
I'll give an example without giving too much away - if I can.
Ex: Workflow application for reposession companies.
Most reposession companies are small, and use their yahoo, gmail,
hotmail, aol accounts to do business - yes, they do. Many of them are
not tech savvy, but always ask why they need two or more user accounts
on the internet if they are one person. The application for them just
lists addresses, fees, days to acquire, etc, so it is nothing big, but
it has become essential to the way they do business.
So, what I have done was slowly migrated everyone to their existing
email account for login purposes. Which works like a charm - with the
exception of the gmail account system, because I don't have a user
hash, or an email to tie the user to. I have told all of the gmail
users to create a calender - which is the only way for me to get their
email address so that I may assign them the correct orders and
associate them with their company. So they log in, then I have to
parse an atom feed just to get a UID for the current user?
As I said before, if it is a security issue with google. Just give us
a UID for each user if not the email, comprised of the requesting
application ID and the email as an MD5Hash maybe. Just something that
doesn't change.
1) Forward to Google Login
2) User logs in
3) Google returns UID for user to website
All we need is
1) User has logged in
2) This user is <blank>
Right now with AuthSub, #2 takes all kind of hacks (Gdata, Calendar,
etc) because of the every changing session ID. Mind you Hotmail/Live,
Yahoo, and AOL have all understood this need for a UID or email and
have implemented it.
I hope this helped a bit. I am building my own application on the side
where I need to do the same thing - and the majority of my user-base
have gmail and yahoo accounts, so this feature would help a great
deal, instead of me telling my users that they need to create a
calendar just to login...
Highly agree. In fact, I just want to use Google Account like OpenID.
My website has some subdomains, like g.xxx.com, o.xxx.com, etc. The users who use g.xxx.com have Google Accounts to login, and the users who use o.xxx.com have OpenIDs to login. All these subdomains are mostly same except the account system.
On Dec 29, 2007 12:08 PM, maufau <mau...@gmail.com> wrote:
> I'd love to show the use case for this - however this is a feature of > my companies (as of now) private application.
> I'll give an example without giving too much away - if I can.
> Ex: Workflow application for reposession companies.
> Most reposession companies are small, and use their yahoo, gmail, > hotmail, aol accounts to do business - yes, they do. Many of them are > not tech savvy, but always ask why they need two or more user accounts > on the internet if they are one person. The application for them just > lists addresses, fees, days to acquire, etc, so it is nothing big, but > it has become essential to the way they do business.
> So, what I have done was slowly migrated everyone to their existing > email account for login purposes. Which works like a charm - with the > exception of the gmail account system, because I don't have a user > hash, or an email to tie the user to. I have told all of the gmail > users to create a calender - which is the only way for me to get their > email address so that I may assign them the correct orders and > associate them with their company. So they log in, then I have to > parse an atom feed just to get a UID for the current user?
> As I said before, if it is a security issue with google. Just give us > a UID for each user if not the email, comprised of the requesting > application ID and the email as an MD5Hash maybe. Just something that > doesn't change.
> 1) Forward to Google Login > 2) User logs in > 3) Google returns UID for user to website
> All we need is
> 1) User has logged in > 2) This user is <blank>
> Right now with AuthSub, #2 takes all kind of hacks (Gdata, Calendar, > etc) because of the every changing session ID. Mind you Hotmail/Live, > Yahoo, and AOL have all understood this need for a UID or email and > have implemented it.
> I hope this helped a bit. I am building my own application on the side > where I need to do the same thing - and the majority of my user-base > have gmail and yahoo accounts, so this feature would help a great > deal, instead of me telling my users that they need to create a > calendar just to login...
Any news or updates on this? I understand that things take time.
However, in the interim or as a solution, can google just do something
really simple?
We all know that google stores an ID for each user, - so can you give
us the MD5 of the userid using our appid as salt? This way, it will be
unique per app, per user, but static if they return to the site. so
simple.
Doing it this way, google will not be giving away the username or the
email, just a unique identifier. Just create another gdata app that
supports this call : get_UserHash()
I still to this day do not understand how google can not understand
the use of this request, when all of the others (yahoo, aim, live)
have implemented it right out of the box. We need to be able to track
our users, and do stuff like - show them their previous purchases,
show them their previous downloads, tie their email to their company
if we a web based CRM, or management software Our users love their
gmail accounts, we love ours too, so we want to provide them with the
service that they expect.
Yes, we use the users calendar in our apps, great implementation for
the most part, and we export to google spreadsheets as well, so - can
we just get some form of static unique ID per user, and not an ever
changing session? Make this thing easier for us trying to use your
service?
On Dec 22 2007, 12:00 pm, Vince Wu <v...@google.com> wrote:
> Do you have a public website? I'd like to learn more about what kind
> of sites have this demand.
> On Dec 21, 8:58 pm, xushiwei <xushiwe...@gmail.com> wrote:
> > I have the same demand too.
> > On Dec 18, 3:21 pm, chrisff <chris.fi...@gmail.com> wrote:
> > > I'd love to see it to for the exact same reasons thatmaufausuggests
> > > and for the same reasons that Yahoo provides this service. Basically,
> > > we want to use it like OpenID.
> > > I don't want users to have to remember another userid and password for
> > > my site, so I want them to be able to authenticate to Yahoo/MSN/Google/
> > > OpenID/Facebook, who will then pass back to my site a consistent and
> > > unique anonymous user-hash that I can identify that user when they
> > > come back to my site and sign in again.
> > > On Dec 14, 10:15 am, Vince Wu <v...@google.com> wrote:
> > > > Hi - thanks for your email. This request has come up several times
> > > > before, and we understand there is demand for it. Could you give a bit
> > > > more background to your use case? A pointer to your website would be
> > > > easiest if your site is already public.
> > > > Vince.
> > > > On Dec 13, 7:51 pm,maufau<mau...@gmail.com> wrote:
> > > > > I know that as of right now - we cant get this information user's
> > > > > email address based on authsub. This is fine but I'm sure many other
> > > > > users not just myself would like to know why as well. if there was an
> > > > > answer can some one point me to it? Besides the "google doesn't...", I
> > > > > am asking: Why?
> > > > > And if it is a security issue - is it too hard to give us a user hash
> > > > > (MD5 maybe) using the username as the data and the appid as the salt?
> > > > > Or better still so that we can't rev-eng the data, the internal google
> > > > > user_id and the app_id as salt - same MD5, or some one way encryption
> > > > > - something. From what I understand,
> > > > > this doesn't take any storage or large memory cycles to do this. Just
> > > > > return it to us - you don't even have to store it.
> > > > > THE BIG QUESTION
> > > > > How do we tie returning user's to a gmail account? I have plenty of
> > > > > hacks to do this with (user calendar, google base) - but these are
> > > > > extra steps, that aren't really needed for something so simple.
> > > > > We are all internet users -
> > > > > Google, Hotmail, Yahoo, AIM hold the keys to ridding the internet of
> > > > > the [register] step for websites - Yahoo and AIM have already taken
> > > > > the initiative to allow their users to login to authorized websites
> > > > > and return a unique id,
> > > > > Live is working on theirs now (not passport) - and they provide us
> > > > > with ways to tie their user - back to our accounts
> > > > > If this optional parameter equals '1', the Yahoo! login server
> > > > > includes an unique identifier for a particular user in your endpoint
> > > > > URL. With the userhash you can identify a returning user or even build
> > > > > an application that requires sign in without having to build the
> > > > > authentication part yourself. The identifier is bound to a specific
> > > > > appid.
> > > > > Validates the Authentication Token issued and returns user's loginId
> > > > > and displayName along with last authentication time stamp. The getInfo
> > > > > method can be invoked in a browser either as a redirect or as a JSON/
> > > > > JSONP call from the browser.
> > > > > I mean - its right there - this is all we are asking for.
I second that request. I am building a webapp that should allow every
google mail (or apps user in general) user to login to my webapp.
Basically I just want to do authentication, but as I store data users
add in my web app, I need to identify them, when they return. Later on
I want to add features from the google apps portfolio to my site.
