Tag Archives: angularjs

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.

 

[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.

 

 

Angular Translate on Angular JS 2 and Ionic Framework 2

Yes, finally I made it work.

What were the main issues?

  1. I had a lot of peer dependencies errors while installing ng2-translate. Apparently, I can ignore them all.
  2. The right dependencies need to be loaded on your app.ts and page.ts for the plugin to work.

Things to take note of, we load the bulk of the initialisation and config of the ng2-translate plugin in the bootstrap file, aka the app.ts, which serves as the root of your app. In Ionic1, this would be the app.js

This file serves as the base structure upon which you will load the other components upon.

Remember to call the translate service in the constructor! I suppose I am only having this problem now because I am new to AngularJS 2. In future, this should come in as second nature.

Here are the two files that are needed to make this Ionic Framework 2 implementation of ng2-translate run.

Many thanks to Olivier Combe for creating the Angular JS 2 port @ https://github.com/ocombe/ng2-translate

But seriously, the code examples needed to be clearer and more ‘plug and play’.

It was missing import {Http} from '@angular/http'; in the bootstrap file, and it wasn’t clear how the bootstrap and the component files should look like, once installed correctly. But anyway, here you go.

app.ts

 

startup.ts

 

Using SCSS/SASS with AngularJS2 components

So previously, I’ve talked about how in AngularJS 2, you can include individual styles/stylesheets to be used exclusively by the respective component.

Problem is, this only natively supports CSS, which is quite a bummer.

From what I could see, there are two ways to go about this:

  1. Compile all SCSS files in the component folders, and concatenate them into one app.css
    This would mean that you will have to forego the encapsulation feature though, as there will no way for the components to know what styles are theirs.
  2. Compile all SCSS files in the component folders, save CSS files in the respective component folders, and load those generated css files instead.
    This seems to me, the more logical approach as the intended behaviour will be retained.
    Problem is, this means that your task runner will potentially be watching 100 scss files in 100 folders (or more) and compiling them. Maybe this isn’t such a big deal, I don’t know yet.
  3. Someone has also written about this at https://github.com/AngularClass/angular2-webpack-starter/wiki/How-to-include-SCSS-in-components.
    Apparently there is a solution using the Webpack task runner. However, to me, this seems to be adding a lot of bulk to the project, especially when I am already well-versed with Gulp/Grunt, and Ionic Framework already have their SCSS compilers in place.
    If I am not mistaken, going this route will allow your angularJS 2 components to load the SCSS files directly. The runner will process the SCSS files upon request, and return them as CSS strings.

Notable Issues

It’s worth noting that having multiple independent scss files are neat and all, however, they actually add overhead to the load times. Every thing you include, be it a view template or a scss file, is an additional http request.

That’s why it is recommended to embed your html template within your component’s Typescript file using template: <h1>Hello</h1>  if the code is small and lean (which is the goal).

Styles-wise, it would be perfect if we could simply enter SCSS code into the styles attribute, and the app would be able to compile the resulting scss into css.

That would be the best solution in my opinion, and we can get rid of all these processes, although there will be similar processes happening in the background, but it will feel seamless.

 

Strategy for migrating from Hybrid apps to Native

So I’ve decided on a strategy to migrate from programming for hybrid, web-based apps using AngularJS 1 and Ionic Framework 1, to eventually, native Swift 3.

The route will be:

AngularJS 2 -> Ionic Framework 2 -> Swift 3

After getting my hands dirty for a few days in AngularJS 2 and Ionic Framework 2, I realised that the new way of doing things in both frameworks are shifting very closely to the paradigm of Native Apps.

Everything is not kept very modular, in components. In fact, i think that after we’ve mastered AngularJS 2, it will probably be a piece of cake to learn ReactJS too, because there are many similarities.

I can already see once we’ve migrated our AngularJS1 app to 2, that the code will be immensely more maintainable, more re-usable.

How so you ask?

First of all, AngularJS 2 adopts a Single Responsibility Principle, throughout the app. This means that every function, service, component (controller) should have one use. These individual components can then be combined in a view to form a page/screen/UI.

This has always been a rising and recommended principle for all programming languages, and is now becoming the requirement.

More interestingly in AngularJS2, is not only are the programming logic Single Responsibility, even the assets are.

We now work with a folder structure like so:

/Listing/
listing.ts
listing.html
listing.scss

The controller, view and scss are all contained in the same component folder! An even cooler thing is that when you declare the style/stylesheet for use in the controller, that style/stylesheet ONLY applies to that component! This is done through encapsulation, whereby the component will render a dynamic class every time, and apply the styles only to that class. This is a huge paradigm change!

Doing things this way also makes testing much more efficient and straight forward.

If you need a team member to work on the listing page, you simply point them to the listing page. Chances of them fucking up the rest of the site accidentally is minimal, since the component they are working with has a single responsibility.

Native apps, ReactJS also follow the same principles, which make AngularJS 2 definitely the way to go for the future.