Archive for: December, 2016

Laravel 5.3 Passport Oauth woes

Ok I’m about 2 weeks into my head first dive into AngularJS 2 and Laravel 5.3.

I’m approaching Angular JS 2 from 1, but going into Laravel pretty much from scratch (with prior PHP experience), so there were/are alot of new paradigms to get used to.

So far, it’s been pretty mind blowing on how easy it is to accomplish things, provided one gets the syntax and methodology correct. In both AngularJS2 and Laravel 5, one would notice that there is a lot more ‘setting up’ to do before one gets to coding a new feature, be it with a new controller or service. But it all works out well, because in the end, the code and data is more structured.

I was particularly impressed with how the Eloquent ORM system in Laravel, where I define my database table relationships, and simply let Laravel handle all relational calls from there. Mindblowing.

My social media app is coming along very well so far, with AngularJS 2 as the frontend, and Laravel 5 serving as the API and future backend management.

Now on to my problem. User Auth.

A classic user auth via login form is easy as pie with Laravel, however since I’m building an API, I need something different. Passport was supposed to be the answer, but apparently it is not, or not as easy as I thought it would be.

You see, Passport is meant to be a way for one to build an OAuth server in minutes.

An OAuth server however, is not quite simply a login mechanism. I mean, part of it IS providing a means for user to get authenticated (log in), but to put it in layman terms, it’s like building Pinterest just so I can find a way to upload my photos a website.

Passport in fact seems to be at it’s core, creating a separate OAuth server, for Clients/Consumers (which confuses me to be honest), for sake of simplicity, let’s refer to Client as Our App. So the Passport implementation would act as Facebook, when we’re using Facebook Connect to login to Our App, but let’s refer to it simply as Passport.

So, in reality, one would find a ‘Connect with Passport’ button on Our App.

The user clicks on that button, and gets redirected to Passport. If the user is logged in on Passport, they get a dialog asking for permission to share their info with Our App.

User clicks yes, and they are redirected back to Our App with the access tokens.

Our App processes and stores that token information to determine user is logged in.

Done. Simple.

This methodology works if we are trying to login from a 3rd party website with our Passport credentials.

Problem 1
Our App and Passport is in fact the same platform. We are not trying to Connect with Passport, we are trying to Login to Our App.

Problem 2
We need to implement our Auth as an API, without redirects and confirmation on a web page.

There are some comments on threads saying “That’s the whole purpose of OAuth! So you don’t have to login with username/password!”

That is a stupid statement, because OAuth works by using credentials that you already logged into in the Passport server. You only don’t need to log in on Our App. At some point in time, you ALWAYS have to do a username/password login somewhere, as the basis of your authenticated user.

Which simply means, that in this single server/app implementation, OAuth is completely irrelevant!

Question then is..

Can we leverage Passport to just perform login auth and create tokens?

Seems like the Generate Personal Token is the way? It generates a token based on the logged in user to use freely, without requiring any authentication. Are there any security concerns though?

Maybe not, looks like what we’re looking at is Consuming our own API

Consuming own API is simply setting the Web Requests on Laravel to always generate an api token in cookies, so requests are authenticated. API Requests first look for authorization headers, if they don’t exist, then it looks for the cookie token.

At this points, it looks like a combination of Generating Personal Token, AND enabling Consuming Own API.

I’ve also come across some people saying the answer is Grant Password.

Ok after a lot of thinking, I finally understood the paradigm.

I was right when I said it was kind of overkill to use the Laravel Passport as a login mechanism. That said, it is also easy to leverage it for use in a self owned frontend + api.

Here’s the process.

  1. Create Sign Up APIs, using the built in Laravel Auth Methods. Nothing to do with Passport here.
  2. The Login API is simply a call to the OAuth method to retrieve a Password Grant. The params for the password grant require username and password, which acts as the login as well. A successful auth will return the token to be used.

That, is fucking it.

Look, the other OAuth functionality is only if you want OTHER apps to use YOUR PLATFORM as a means of logging in. Not the other way round.

So if you were actually coding something called AngstyCoders.com , and make full use of Laravel Passport,  Stack Overflow might one day have an option for people to Connect with AngstyCoders, which then is when you would fully utilise Laravel’s Passport OAuth features.

 

Laravel Passport Routes Not Found

Woes of a programmer.

The building process actually is very satisfying and quick.

It is when shit that is unexplained happens, and you spend many hours, even days to troubleshoot and solve the problem that makes you want to pull your hair out.

In this case, I am experiencing a series of 404 errors in my Laravel Passport implementation.

It was working fine before when I first tested the project, back when the project was quite blank.

Suddenly now, upon loading the Vue frontend for the OAuth server, I get a 404 route not found for all the OAuth routes, /clients, /tokens, /personal-access-tokens, /scopes

WHY???

Conclusion

Sorry to disappoint, couldn’t find the cause.

Started a fresh Laravel installation, installed Passport and the Vue Frontend, verified it worked, Installed Laravel/Cors plugin, which I thought was the cause, verified everything worked, everything worked.

Copied over all the controllers and services I did before, everything works.

Fuck you very much. 6 hours of my life I’m never getting back.

 

[AngularJS] Updating parent scope from a directive

Here’s the scenario.

I had a settings page for opening hours for a restaurant, which you set opening hours from Monday – Sunday.

I implemented a button on Monday, that allows you to use the same settings for all other days.

I bind this button to a directive, to capture the values of Monday, and then loop through Tues-Sun, clearing their select boxes, and populating them with the select boxes according to what Monday is set. (The reason why I’m not directly changing their ng-model value is because we can set multiple opening hours per day, which is done via an array in ng-model)

So far, the values get populated on screen beautifully. Upon clicking Save, I realised something:

THE VALUES FOR TUES – SUN ARE EMPTY

The reason was because, i was setting the values in the directive via scope.tue_start, scope.tue_end, etc.

That meant I was setting the hours to these variables for the scope of the directive, NOT the parent/page.

So the question came down to:

How do I update the parent scope from within a directive?

After alot of headaches and searching, I finally found the syntax.

from within a directive, to access the parent scope, use

scope.$parent.xxx

Some other people suggested defining a method in the parent scope to update the values, ie. updateOpeningHours(day)

And then calling that method from the directive scope. I haven’t given it a try, although I see it as a modular approach, for now, I’m quite happy with this simpler syntax.