I'm building a web application for a customer and I'm not really sure I'm doing the right thing...
Basically, I created a PHP application that read, edit, delete calendars on Google and keeps a copy on my own web application DB (for various reasons). Now, I read about the OAuth 2.0 and realise it could be safer to use this than have my client general Google password (that access ALL google services (calendar, email, etc)) directly in my web app in a PHP file (in other words, if a hacker enter the server than he can steal her password...).
So I created the OAuth 2.0 account, add the classes/folders from this page http://code.google.com/apis/calendar/v3/using.html#setup and added the proper scripts on a test page to "authorize access to your information" (see "Instantiating the client " in the same page) ...
Here is my questions: If I am logged in my gmail with MY login info (not my Client) and I go to my test page, it will ask ME to authorize access to my Google Calendar. But I want my client's calendar, NOT MINE! So, let's pretend I logout, log in with my customer info and go to the test page : it's perfect, I authorize the account, then I'm redirected to my app where i can see HER calendar.
But this is not practical OR logical... Since, for example, I want people on her GENERAL PUBLIC website to go on a page, and fill a form in order to automate her appointments. The script must check her google calendar.... and ask permission for THEIR gmail accounts? No, I want HER calendar.
So this is my problem / question. What am I doing wrong? Is this the right way to do so or did I miss a step? Was this API meant to do this?
How can I use the API to work in the way described above?
Thanks all to light my candle
Joel
If I'm understanding you correctly, you've got the authentication right. The problem is that you don't want to display the calendar of the logged-in user; you want to display your client's calendar.
A user can write to a calendar in one of two circumstances:
The user owns the calendar, or
The owner has given write access to the user explicitly, by specifying the user's email address.
Clearly the second situation doesn't scale. And in either case, you'd need to embed your client's credentials in your application, then use them either to create appointments on behalf of an authenticated user, or to share the calendar with the user. Of course, you'll want to encrypt your client's credentials--don't simply hard-code them in your app!
Rather than using your client's "real" account, it would seem more secure to create a new account (with a unique email address and password) specifically for this calendar. Your client could then access it through your application as her customers would, or you could share the calendar with her and give her write access.
Another possibility might be to make the calendar read-only to the users, and rather than allowing them to create appointments directly on your client's calendar, your app could let them request appointments: it would create the events on the users' calendars and send invitations to your client's calendar. Then your app won't need any embedded credentials. It would also give your client the opportunity to confirm or decline each appointment, automatically sending her response to her users. Another benefit is that each user's appointments would appear on his/her own personal Google calendar.
I'd be interested to know if you (or anyone else) finds a better solution.
I have the same problem, i solved using zend framework, even if i don't like it as it is yet and i'm trying to do with google api directly. ( and i'm not able )
Zend wrap around them i suppose.
I know the question is very old anyway, i embeded zend loader class, and a calendar extension.
Then i just use:
if($something) {
$client = getClientLoginHttpClient($usergmail, $passgmail);
createEvent($client,$dbcon,$id_event);
}
where $dbcon is a connection to my dv, and $id_event is an id where i can find the data i want insert, ( date, content, title, time and so on ).
I don't like it but it works.
Related
I've spent a week trying to figure this out, and I am turning to the experts on Stack Overflow for a little help.
The Concept
I've designed a front-end and a back-end that are relatively separate. Members interact with a Client-side application that runs on Angular4 frameworks. For that, I use the Javascript SDK to control Facebook login. The application does not use Facebook for anything more than login and pixel information, so I request bare minimum permissions (thus bypassing any need for application review also).
On the back-end, I store the facebook ID of the members. The facebook ID is their unique identifier, since not all users will have an email address. If the member has a paid subscription to the site, the backend needs to invite them to a group page that has SECRET privacy setting. Membership to this exclusive group is one of the perks of paid membership.
The Problem
Here's the problem, to send a member invite, I need a CLIENT_TOKEN from a group administrator. OR I need to have a CLIENT_TOKEN for my APP, if the page that is created was created by the app itself.
What I have found
Facebook API documentation on the CLIENT_TOKEN is very sparse. The documentation includes redirects where the user supposedly enters their user-name, password and then, when they return, a CLIENT_TOKEN is passed back with the redirect. However, this does not work for the Backend, because the admin user (me) is not going to be available to interact with the page that is loaded on the redirect.
I thought about creating the group with the APP to utilize the CLIENT_TOKEN that is owned by the APP itself. However, the documentation (current link pointed to by the current API, btw) notes that APP groups are deprecated, so this is not an option.
What I need to know
Here is what I need to know:
1) How do I obtain a CLIENT_TOKEN for my personal user account without being present to authenticate each time it is requested?
2) In addition to the above, do you have any other advice or tips that I might have forgotten to ask about that pertains to programmatically inviting and removing members?
You can not send invite requests for a group to users via API.
That was a feature available specifically for App & Game Groups as well, but is gone with them.
I'm working with a team on a webapp that will use an existing database with client data, but has no user accounts setup. The goal is to have users perform an email lookup in the database to see if their info already exists, that way if we find them, we can tie the existing data to their new user account.
We'd also like to implement OAuth so that users are able to login via facebook or google, but we're a bit unsure on how to link these third-party accounts to our own. We can request the email back and check it against our DB (assuming the user grants us access), but that would be a big assumption of them having the same email in our system as their other accounts.
Getting to the actual point, we're curious as to how others have implemented this workflow. Would it be better to force the user to check for their email first when selecting one of those options? or roll the dice with a lookup? Should we hide the option to login via third-party and only allow them to associate a third-party account after they login (so they would automatically login to our site assuming they're logged in elsewhere)? Or would it be best to let them build a new account, and provide admin tools to link local data to an account after the fact?
Sorry for the open-ended question, I'm sure I'll get some downvotes here (don't hate me), but I've been scouring the internet for a while with very little to show for it, and I feel that the StackOverflow community is one of the best Q&A resources out there (love you guys).
Thank you in advance!
Since you already have client data - it will be a bad move to force all those users to do something - anything really. So, unless you are cardinally changing way too many things - you must smoothly move them over to the new opportunities in your app.
For the old users - offer to login with their existing account, and offer to add social network (maybe some notice at the top of the window about it), with which they can authenticate afterwards.
For the new users - offer to create an account like old users, and also offer to create account by using oauth.
I have this app that uses data from gmail accounts. I have been able to create a php site that retrieves the oAuth tokens (online and offline) and later the necessary user information from the mailbox, all using the Google php api. Now to my problem:
When a secondary user logs into gmail in a browser that was previously used by an authorized user, the credentials seems to "stay". So the 2nd (or 3rd or nth user) can see data non-related to them, which is also a security hole. But most important: every loged in user into gmail is seeing only the data of the 1st logged in user.
The question: Is there a way I can use Google PHP API or Google JavaScript API to retrieve the user name of the current gmail session?
This is the current php piece of code I've been using to retrieve the user data:
use google\appengine\api\users\User;
use google\appengine\api\users\UserService;
session_start();
$user = UserService::getCurrentUser();
$userEmail = htmlspecialchars($user->getEmail());
The idea is that the app uses the current gmail user information to query a database and then retrieve the data for that specific user - and only that logged in user. If the user is not authorized, then prompt for the authorization window and ask for permission.
Any ideas or suggestions are welcome.
UPDATE (Sept 7, 2015):
I have made a change in the app.yaml so every logged in user in gmail gets served a different uri from my app. That works just fine. Now I face a new issue: how can I make the PHPSESSID and SACSID cookies to use an specific path instead of the whole domain? That way - theoretically - I can have several logged in users each and every one connecting to a different subfolder.
I've read the whole documentation about the UserService but it seems all I can do is redirect to this:
UserService::createLoginURL($_SERVER['REQUEST_URI']);
And that takes care of the authentication.
The question: How can I restringe the scope so the cookies gets the appropriate folder path?
The main issue is that once you log in to App Engine (via the UserService), that a user session has now been created in your App Engine application, and therefore it doesn't really matter what you do in GMail or any other Google application, as the session has already been created, and persists within your application.
The App Engine UserService was available way before secondary logins were even possible, and it hasn't been updated since. So this use case probably wasn't a consideration when the API as developed.
I am working on a website which will allow registered users to link with their Facebook account and periodically, the site will poll their information and post back to their Facebook page.
The site is Joomla based, so using the PHP API seemed most sensible, but I'm not sure.
I've looked at the Facebook documentation and it seems confusing. Do I need to write an app and get it approved, or is there a simpler way?
If I need to write an app, is there anyway to develop and debug the app before getting approval and only turn off sandbox mode after approval has been achieved?
What would be the simplest way to implement this so I can retrieve some Facebook info and make posts to Facebook pages at later dates?
In future, I may wish to allow users who are logged into Facebook to automatically login to my site, but for now, I do not want this.
You will need to register an application. Being that this is not an application hosted on facebook, there really isn't much of an approval process.
PHP SDK would be required for what you want to do.
In order to post to facebook or get facebook account information, the user would need to authorize your application and provide permission for what you want to do.
Keep in mind that although a user can grant your application a key via which you can do things on their behalf on facebook, this key will eventually expire if the user does not return to your application.
I would take a look at the Facebook API that was done for summer of code. It is currently in the platform tracker and you also need the OAuth1 API that she did. If if you use that you'll have a good start on what you need.
This is a tough question to ask so I hope I can make it clear!
I'm writing a PHP script that access a users Gmail calendar. I first wrote it using Zend and it was fantastic, but found that I have to use the Oauth to get to tasks - therefore I rewrote it for Oauth instead.
In order to use Oauth I have to go to my API console and set up the account and then I have access and everything works great. Here is my problem: I can't ask every single user to go through this somewhat technical step of creating a key and all of that just so my app can work with their Gmail.
Zend was really easy, the user provides me with their name and password and I have access. Now I don't see any way to change accounts using the Oauth method, all of the credentials are for a SINGLE Gmail account (as far as I can tell).
Is there a way to do what I'm trying to do without making the users go through fifteen hoops to allow me access? I would like to register my app and get my keys, then be able to point to ANY Gmail account, the user grant me access, and I'm in. Otherwise each user has to go to the API console in their own Gmail, create branding, create a key and then create a server ID, THEN provide that all to me so I can plug it in and THEN redirect them back to Google so they can say "yes, I accept this". That's a lot of steps to integrate.
I hope this was clear enough :).
That's basically how OAuth works. ONLY the developer that wrote the app needs to register it, get the keys and add that to the configuration.
Users of the app simply get taken to a page (after signing into their Google account) where they will grant access to your app in a single click. Google will remember their decision and the next time will be even faster.