I have a question maybe useful for most of Laravel developers.
I want to allow user to connect to one or more of these APIs:
Google Login
Google Calendar
Google Drive
I have used Laravel Socialite so far, which provides clear connection to many social accounts. My issue is that through Socialite I have only one google Driver, while I need to address to different Google API from different buttons.
My .env data, connected to the config/services.php are:
GOOGLE_CLIENT_ID=1.apps.googleusercontent.com
GOOGLE_CLIENT_SECRET=XXX
GOOGLE_CALLBACK_URL=https://mysite/google/login_callback
GOOGLE_CALENDAR_CLIENT_ID=2.apps.googleusercontent.com
GOOGLE_CALENDAR_CLIENT_SECRET=YYY
GOOGLE_CALENDAR_CALLBACK_URL=https://mysite/google/calendar_callback
GOOGLE_DRIVE_CLIENT_ID=3.apps.googleusercontent.com
GOOGLE_DRIVE_CLIENT_SECRET=WWW
GOOGLE_DRIVE_CALLBACK_URL=https://mysite/google/drive_callback
Now, it is now clear to me how to manage multiple APIs from different buttons. Here some options:
Use Socialite with unique credential entry point (google_login) from Google Console Cloud and in the callback function into the Controller I differentiate different cases (login, calendar, drive...)
I create a different Google credential for each API into API section, I use Socialite only for login and I create/download separate package for Calendar, for Drive, etc...
So the main point is: multiple Google APIs in Laravel need to be applied with unique API credential and at Controller level I address to relative code using scopes or I have to create a separate API credential of each API, make the relevant .env keys and the manage all separately.
I hope to have been not to much blur.
thanks!
With the socialite package, you can only do authentication. If you are developing for Calendar and Drive, I would suggest to use google client library
$client = new \Google_Client();
$client->setAccessToken($accessToken);
$client->setSubject($email);
$clien->addScope(['{scopes}']);
$client->authorize();
$client->get('https://www.googleapis.com/calendar/v3/calendars/' . $calendar_id . '/events');
Please also refer this document: Event apis
Drive Apis
Related
I'm working on a Laravel site where users could connect their Google account and manage their Google calendars directly from within the site. I found https://github.com/spatie/laravel-google-calendar but I'm not sure that it really meets my needs.
That package doesn't seem to follow the authentication flow (OAuth 2) I'm used to with other APIs. It uses service accounts and stores credentials in JSON files where I usually save access and refresh tokens in my users table.
So am I missing something or is that package not made for that kind of site ?
I have a platform that allows people to sign up/log in with their Google account.
Inside the platform, there is a calendar feature where people can connect their Google Calendar and share the data between our app.
I'd like to know if there's a way to separate google calendar with the normal login stuff, so when they sign up with Google, we won't be asking for their Google Calendar permission. Once they are in the app, if they want to connect their Google Calendar, they can do so by clicking another button.
Currently, the 2 things are linked together and I'd like to separate them.
My app is https://clascity.com/
Any help is greatly appreciated!
Just because you use Google signin (openid connect) does not mean that you have permission to access the users Google calendar data.
Google calendar data is private user data, you need specific permission to access the users calendar data, you cant just let them login without asking for permission to access the data you need to access. The user needs to know what data you will be accessing and accept that specifically though the authorization form that google supplies.
Yes, in fact, what you are suggesting is considered a best practice [1]. Use incremental authorization as described here [2].
[1] https://developers.google.com/identity/protocols/oauth2/policies#unbundled-consent
[2]
https://developers.google.com/identity/sign-in/web/incremental-auth
I read https://laravel.com/docs/6.x/passport now and it is clear technically, but in which cases have I to use it to get
advantage comparing with laravel native auth or jwt/auth I worked before?
1) In config/auth.php 'guards' we set which auth driver would be used in the app
and it can be only 1 set. I mean we can not set passport and jwt/auth in 1 app?
2) Looks like passport can be used in case when we use blade page and form is submitted as we do in blade page as :
<form method="POST" action="{{ route('register') }}">
#csrf
I suppose there is no difference in blade forms definition using passport intead of native auth?
3) Also, passport can be used instead of jwt/auth in backend rest API and there is no difference in work of clients app
using this backend rest API ?
4) Is passport better/has some advantage in both cases or it is just one more replacement?
5) Please give some examples in which passport can be used / got advantage of using it may be in some other app types?
Thanks!
Laravel Passport is a Laravel package that allows you to integrate the OAUTH2 protocol into your application.
This means that when you want other services to retrieve user data from your application, or add data, they can request access for users. Users can give permissions for certain actions by clicking a button on the external site, logging in on their account on your Laravel site, and allowing access for the external service. Users are then redirected back to the other website, and after a few requests between the two servers, the external service now has the requested permissions to read or alter user data. This protocol is almost always used whenever you click "sign on with ..." since all large social media platforms have OAUTH2 integrations.
To answer your questions:
I believe this question: Laravel combine Passport authentication and normal authentication will answer your question.
Passport sits on top of default Laravel auth and needs this to authenticate requests. So users still have to have an account on your site to allow other websites to access your account.
There are big differences in how normal API auth works, and how Passport works. The biggest difference is that normal API auth should only be used for your site, not for external sites to fetch user data from your API. With OAUTH2, users can give certain permissions to websites, and using tokens, these external sites can perform certain actions on your site.
If you want to allow other sites to fetch account information from your site, you should implement Passport, if not, then using Passport has no large advantages.
Examples are things like Sign in with Google, or with Facebook, Twitter or GitHub, Even stackoverflow has an OAUTH2 implementation. Services can, for example, create new Facebook posts for a user, request all twitter posts from the last year or create a new issue in Github.
i am creating an app using google apis.i need to access user's documents through google apis using google admin account.In past i can use google docs api like this
for example i am admin of domain iritesh.com and my email address is ritesh#iritesh.com.i logged in using admin account and can retrieve documents in google drive of rajat#iritesh.com using user_id = rajat#iritesh.com.
https://docs.google.com/feeds/"+user_id+"/private/full/folder:root/contents?v=3&alt=json
but now google docs api's are deprecated.can anyone please guideline How to acheive this using google apis now.
link reference : https://developers.google.com/google-apps/documents-list/#using_google_apps_administrative_access_to_impersonate_other_domain_users
With the new API's and OAuth 2 you can accomplish this functionality but for it you will have to use Service account with domain wide delegation.
Basically with the service account it would be possible to impersonate users in the domain and make API calls in user's behalf. For getting information about documents you will use the Drive API.
Here is the documentation on service account:
https://developers.google.com/accounts/docs/OAuth2ServiceAccount
And Drive API:
https://developers.google.com/drive/v2/reference/
hope this helps.
I'm building mobile applications using .NET. What I'm looking for is a way to manage user sessions and info using Azure Mobile Services. I've read a lot about the authentication in Azure Mobile Services, but this only authenticates a user via Facebook, Twitter, etc ... to access azure services.
I'm looking for user session management, i.e. register, login, logout. Be able to save and retrieve user info, i.e., save certain info against the user such as age for example. Also session management and caching, i.e. the user will remain logged on when the app is closed and re-opened. Also azure mobile services doesn't seem to provide a way to allow me to register users via email.
Basically, If anyone is familiar with Parse, I'm looking for having similar functionality in Azure. Can anyone help please ?
Thanks
Out of the box, Mobile Services provides easy authentication with social providers (Facebook, Twitter, etc) and Azure Active Directory. If you want to do registration via email, you'll have to create a custom auth system. This is going to be more complex than just flipping a switch and using Facebook auth, but totally doable and I can point you in the right direction. First, check out this post that will explain how you can create a registration / login system using custom API and the script backend. If you're using a .NET backend, you'll need to alter thing a bit (the samples are in JS) but it should be pretty easy to convert. The only piece that is really missing from that post is how to do email verification. To do this with Mobile Services, I would suggest the following.
Sign up for a SendGrid account (free in the Azure store)
From your script, after registering the user, generate a random alphanumeric string that is saved to their account / user record in the table.
Use the same string to create a URL which you can send to the user's email address (check out this tutorial for sending email via SendGrid and Mobile Services).
The link can either go to a different custom API or a web front end. When that endpoint is hit, it should update the user record to show that they have verified their email address.