Member
I'm not sure where the best place to have a discussion about the dev branch of things is but I figured here would be a good start.
I was looking at the dev "Federated Login" plugin and noticed that when a user logs in via the federated login it generates a username someting along the lines of "Google:askjf;aowieurawa" or whatever the session response is I assume.
I'll really dig in this weekend to see if there's a reason why, but wouldn't it make more sense to set the user's name to be the same as the federated login name instead of the session info?
Cause I guarantee that very few people will think to write down the info.
Or perhaps I'm missing what the federated login should be doing...
Is it allowing them one-time viewer access only?
Perhaps it could be used to setup actual Zenphoto user accounts.
I'll dig into this more this weekend when I am off work and attempting the facebook connect/login functionality.
I was looking at the dev "Federated Login" plugin and noticed that when a user logs in via the federated login it generates a username someting along the lines of "Google:askjf;aowieurawa" or whatever the session response is I assume.
I'll really dig in this weekend to see if there's a reason why, but wouldn't it make more sense to set the user's name to be the same as the federated login name instead of the session info?
Cause I guarantee that very few people will think to write down the info.
Or perhaps I'm missing what the federated login should be doing...
Is it allowing them one-time viewer access only?
Perhaps it could be used to setup actual Zenphoto user accounts.
I'll dig into this more this weekend when I am off work and attempting the facebook connect/login functionality.
Member
The provider of the Federated logon supplies the user identification. Google and Yahoo, for instance supply site unique identifications like you observe. Other providers (MyOpenID) supply the user name of the account.
Bottom line, with Google we have no clue as to the Google user id and cannot get same.
Anyway, no user should really care since they will log in with the Federated provider anyway and that will supply a consistent ID. They would have no way of loggin in using Zenphoto credentials unless they change their password since they will have no clue as to the password we have created for them.
Bottom line, with Google we have no clue as to the Google user id and cannot get same.
Anyway, no user should really care since they will log in with the Federated provider anyway and that will supply a consistent ID. They would have no way of loggin in using Zenphoto credentials unless they change their password since they will have no clue as to the password we have created for them.
Member
Ahhh, I see what you're saying. So with the federated login as long as they're logged into whichever provider they use it will give them logged-in status with zenphoto?
The reason I ask is because that can be accomplished with Facebook as well, but can be extended to pull the info they have and actually create a zenphoto login. Not sure which is the best route to go, but honestly the first is probably the best.
The reason I ask is because that can be accomplished with Facebook as well, but can be extended to pull the info they have and actually create a zenphoto login. Not sure which is the best route to go, but honestly the first is probably the best.
Member
Not quite. Zenphoto "logon" status is cookie maintained. The cookie can expire. At that point the user will have to login again.
If he has Federated credentials he would logon via that provider. Different providers behave differently. For instance, with Google, if you are logged in to your Google account and select the "Google" provider at the Zenphoto logon you will get be get back a Google credential and be logged into Zenphoto with that credential.
There are two protocols that OpenID transaction use to get user information. Federated logon supports both. These protocols are used to request user information from the provider. We request the user's name and e-mail. Unfortunately the provider does not have to furnish this information. All that he has to do is supply an identity. We use the identity as the Zenphoto user id.
I do not know if Facebook is and OpenID provider. They operate as an OpenID consumer at least. If they are a provider then they will support all the above protocols.
Providers can have "discovery" protocols. (That is all that Google supports.) This is basically a URL that the OpenID consumer links to. That URL then figures out "who" the client is, verifies that the site is allowed to get his credentials (usually by asking on the first attempt and remembering the answer.) Then it returns an Identity to the consumer along with any of the requested data that it deems it will support.
Other providers require the full identity URL to validate a user. This is the generic OpenID protocol--what you use if you select the OpenID choice from Zenphoto. What the identity url is will be provider dependent. But it is ofthe something like https://<user id>.provider.com.
Verisign works this way. The Zenphoto Verisign handler first requests the user's Verisign user id then splices together a Verisign Identity URL and sends it off to Verisign for verification.
Your task then is to figure out what Facebook supports and build a handler for it. The Zenphoto Google and Verisign handlers should provide you with a model for whichever mecanism Facebook supports. If they have some third mechanism we will have to figure out how to deal with it.
If he has Federated credentials he would logon via that provider. Different providers behave differently. For instance, with Google, if you are logged in to your Google account and select the "Google" provider at the Zenphoto logon you will get be get back a Google credential and be logged into Zenphoto with that credential.
There are two protocols that OpenID transaction use to get user information. Federated logon supports both. These protocols are used to request user information from the provider. We request the user's name and e-mail. Unfortunately the provider does not have to furnish this information. All that he has to do is supply an identity. We use the identity as the Zenphoto user id.
I do not know if Facebook is and OpenID provider. They operate as an OpenID consumer at least. If they are a provider then they will support all the above protocols.
Providers can have "discovery" protocols. (That is all that Google supports.) This is basically a URL that the OpenID consumer links to. That URL then figures out "who" the client is, verifies that the site is allowed to get his credentials (usually by asking on the first attempt and remembering the answer.) Then it returns an Identity to the consumer along with any of the requested data that it deems it will support.
Other providers require the full identity URL to validate a user. This is the generic OpenID protocol--what you use if you select the OpenID choice from Zenphoto. What the identity url is will be provider dependent. But it is ofthe something like https://<user id>.provider.com.
Verisign works this way. The Zenphoto Verisign handler first requests the user's Verisign user id then splices together a Verisign Identity URL and sends it off to Verisign for verification.
Your task then is to figure out what Facebook supports and build a handler for it. The Zenphoto Google and Verisign handlers should provide you with a model for whichever mecanism Facebook supports. If they have some third mechanism we will have to figure out how to deal with it.