DEV Community: Nicolus

5 essential tools for Laravel development

Nicolus — Sat, 17 Aug 2024 15:45:36 +0000

Everyone loves a listicle right ? So here's one to give a shout out to my favorite tools for PHP/Laravel development

Xdebug

This one is really important to me. I know a lot of people will be happy
with throwing a dd() around when needed and really don't feel like they need a debugger. I wouldn't go as far as to say they're wrong, but I just can't work like that : I need to be able to stop execution anywhere in the code and then inspect the state of every variable, or even change a value before resuming or call a couple of methods from the console to see what happens. This can save you from changing a dd() and restarting the script dozens of times.

I also find that it's particularly useful in conjunction with Unit Tests : Most of the time I'll run my tests in debug mode and go through the code line by line to make sure everything is going according to plan. In this case I'm not using the debugger to track a bug, just as part of my normal workflow.

Clockwork

(Free) https://underground.works/clockwork/

This is another tool that's really useful when developing, it provides a toolbar right in your browser's developer tools that will give you insight as to what happened during each request : Logs, which controller was called, which middlewares, how many database queries, how many cache hits and miss, RAM usage for the request and so on.

I find the most useful part is the Database panel that allows you to see each SQL query that was made (with the parameters already replaced) and how much time it took. It makes it really easy to notice n+1 issues or to find out which query is taking longer than it should.

Mailpit

(Free) https://mailpit.axllent.org/

Mailpit is basically a "fake" SMTP server that instead of actually sending emails will display them in a web UI. This is invaluable for testing locally or in staging because it allows you to test things out without ever risking sending an actual email to a user, while still using actual email addresses in order to check that the recipients, Cc, Bcc are the correct ones.

It's packed with useful features like tagging mails from custom headers, checking links, checking the spam assassin score for your emails, and compatibility with many email clients.

PhpStorm

(Paid) https://www.jetbrains.com/phpstorm/

You probably know PhpStorm already, I'm adding it to that list because it's definitely one of my favorite tools. It is paid, and it is a little heavy and slow compared to a simple text editor, but it provides so many useful features that it's totally worth it for me.

Laravel Idea

(Paid) https://laravel-idea.com/

This one is an even harder sell than PhpStorm as it's only a plugin for the IDE that will provide better support for Laravel, and it's on the expensive side for a plugin. Worse, this is all functionality that in my opinion should be part of PhpStorm. But at the end of the day it makes working with Laravel so much easier, and it make me so much more productive that it's easily worth it : It provides tools to create new Laravel classes (Models, migrations, Commands, Events Jobs...), makes it easy to navigate between all of them, and autocompletes basically everything you could wish for (properties, relationships, validation rules, request fields...).

That's it for me !

I Hope you found something you want to try out, and please share any other tool you like in the comments !

Are PHP objects passed by reference ?

Nicolus — Sat, 08 Oct 2022 07:58:56 +0000

TL;DR : No.

For the longest time I've considered that Objects were "passed by reference" in PHP, and while it may not be technically true, it's a useful simplification that does the job in most cases. So if you read the title and thought "Yes they are" there's no need to panic, everything is probably fine, it doesn't mean that your apps will suddenly blow in your face. On the other hand if you thought "what on earth is a reference ?", you miiight have a few surprises lurking in your codebase, and you're definitely in the right place !

So let's dig in with a refresher on references, then we'll see how it looks like objects are passed by reference, and then why it's actually a bit more complicated than that.

References in PHP

The PHP doc about references tells us that references are "aliases", which means that we can tell PHP we want two variables to point to the same data (the docs also tells us that despite appearances they are not pointers, which is not particularly helpful unless you're already proficient in C). The symbol to create a reference is &.

So we can do :



$a = 'foo'; // $a contains 'foo'
$b = &$a;   // $b is now a reference, or an alias of $a

$b = 'bar' // We're actually changing the content of $a
echo $a    // displays 'bar' (because we just changed the value)
echo $b    // displays 'bar' (because it's still a reference to $a)

This is a nice little oddity, but really not that useful in your everyday code. Now what's a lot more useful is that you can pass variables by reference to a function, so that the function can actually modify the content of the variable outside of its own scope.

This is done by appending the & in front of the parameter in the function declaration.



/**
 * Decrements a number if it's > 0.
 * Returns true if it was decremented, false if it was already 0 or negative;
 */
function decrement(int &$a) {
    if ($a > 0) {
        $a = $a - 1;
        return true;
    }
    return false;
}

$timeLeft = 10;
$wasModified = decrement($timeLeft);

echo $timeLeft; // will output 9

As you can see, this allows us to return something, and modify what was passed to the function directly. This is notably used in the preg_match() function that will return true if something matched, and accept a parameter $m that will be modified to contain what was matched. This is a useful feature, but it could also be the cause of hard to track bugs, so you should probably use this with caution.

Here's a nice animation from this post that illustrates it nicely :

Why objects look like they're passed by reference

It's likely that you've already read somewhere that objects are always passed by reference in PHP. And it sure looks like it.

Take this simple example :



function doStuff($object) {
    $object->data = 'newValue';
}

$object = (object)['data' => 'value'];
doStuff($object);

echo $object->data; // displays 'newValue'

As you can see, there's no & in our function declaration, and yet $object->data now contains 'newValue' instead of 'value'. So the function did modify the object, which indeed looks a whole lot like it was passed by reference.

The issue with modifying objects

Here's a more concrete example that is the source of bugs in actual production codebases. Let's say we want to send our users an email with a receipt for the coming month, and we want the title to display the beginning of the period and the end of the period in a user friendly manner like "From Thursday July 1 to Saturday July 31", and the current date in the footer of the email. We'll create some functions to get the start and end of the month corresponding to the current date, and format them, then use the result in a string (or more realistically a template). It would look like this :



function getFirstDay($date) {
    return $date->modify('first day of this month')->format('l F j');
}

function getLastDay($date) {
    return $date->modify('last day of this month')->format('l F j');
}

$today = new DateTime('2022-07-15');
$firstday = getFirstDay($today);
$lastDay = getLastDay($today);

$emailTitle = "Your receipt for the period from $firstday to $lastDay";
$emailFooter = "Sent on " .  $today->format("l F j");

The title will say
"Your receipt for the period from Thursday July 1 to Saturday July 31", which is what we want, but the footer says "Sent on Saturday July 31", which is definitely not what we want. The issue is that $today was actually modified by the functions when we called ->modify() on the date, so as soon as we use this on a date we lose the original value of the date forever...

There are two ways around this :

1- clone the object before working on it :



function getFirstDay($today) {
    $date = clone $today;
    return $date->modify('first day of this month')
        ->format('l F j');
}

2- Use a library like Carbon 2 that provides Immutable Objects, which are essentially objects where every method always returns a clone instead of modifying the current object.

Why objects aren't really passed by reference

So we've seen that it looks an awful lot like objects are passed by reference and how to avoid potential issues, but the whole point of this post was to show that they're not, so here are a couple examples that make it obvious.

Example 1 : objects in an array

Let's assume a User class that takes the name of the user in the constructor and assigns it to a name property. Now let's see what happens if we put several of those users in an array and pass it to a function that makes the name uppercase for each element :



Class User
{
    public function __construct(public string $name){}
}

function capitalizeNames(array $users) {
    foreach ($users as $user) {
        $user->name = strtoupper($user->name);
    }
}

$users = [
    new User('John'),
    new User('Jack'),
];

capitalizeNames($users);

echo json_encode($users); // [{"name":"JOHN"},{"name":"JACK"}]

As you can see, each user in the array was modified by the capitalizeNames() function.

We didn't use a reference, we never passed an object to the function since we passed an array (by value) so we might think we're safe. And yet every object inside of the array was modified.

Example 2 : Assigning an object to another a variable

Now let's look at what happens if we assign an instance of an object to a new variable :




$user1 = new User('name');
$user2 = $user1;

$user1->name = 'Jack';

echo $user1->name; // Jack
echo $user2->name; // Jack

So basically as soon as we do $user2 = $user1;, we can use both interchangeably and changing one will change the other.

So what happened ?

The thing is that a variable never "contains" an object. Whenever we call new, PHP will return a handle, which is a ~~reference~~... a ~~pointer~~... yeah let's stick with handle. That handle is basically a number that identifies the object.
You can actually see this object identifier when using var_dump(), it's the number with a # in front when dumping an object, here with var_dump($user1, $user2) from our previous example, we can see that they're both the same object since they have the same handle :

You could also use spl_object_id() which returns this object identifier.

Whenever we copy an object variable, pass it to a function or put it in an array, we're not passing or copying the instance of the object, only its handle. So an object will only ever exist once unless we use clone. Kind of like an object in real life.

Conclusion

While it might be useful to think that objects are passed by reference, I think it's better to keep in mind that when you create an object there's only one instance that exists, and what you're using is not the object but simply a handle.

I hope this can be useful to someone. Also I don't have any background in C and only a vague understanding of how this is actually implemented in the PHP core. So if there's something blatantly wrong above please let me know in the comments.

How to properly retrieve Laravel models between two dates

Nicolus — Sat, 05 Jun 2021 14:50:08 +0000

Let's say you have a blog with posts (or an ad board with listings, or travelers with trips... you get the idea) and you want to retrieve all the posts between two dates. Sounds familiar ? So how exactly do we do that ?

The candid approach

It really seems like a trivial question with an easy (but completely wrong) answer : Just use BETWEEN (or in Laravel whereBetween) like so :

$startDate = '2021-06-01';
$endDate = '2021-06-30';

$posts = Post::whereBetween('created_at', [$startDate, $endDate])->get();

We've all done that (at least I know I have) to retrieve all posts created in June. The issue here is that our created_at column is usually a Datetime, so it's not a simple date but it also has a time. Which means that in practice any post created on the 30th won't be retrieved because their creation date will always be greater than 2021-06-30 (which SQL will assume means '2021-06-30 00:00:00').

Or maybe we're using Carbon and have something like that :

$startDate = Carbon::createFromFormat('Y-m-d', '2021-06-01');
$endDate = Carbon::createFromFormat('Y-m-d', '2021-06-30');

$posts = Post::whereBetween('created_at', [$startDate, $endDate])->get();

That's actually even worse because it becomes totally unpredictable. A Carbon instance represents an instant, and it has a time too, except if you don't specify a time it will default to the current time when the script runs. So if you run this script at 9AM and the post was created at 8AM on the 30th, you'll retrieve it... But run the exact same script at 7AM, and you won't retrieve that post anymore because $endDate will actually be '2021-06-30 07:00:00'.

We could use $endDate->toDateString() to get rid of the time, but we'd end up in the situation above.

A better way with carbon

One solution would be to make sure that we specify a time in our query, and that this time is at the very start of the day for our start date (00:00:00) and at the very end of the day for our end date (23:59:59.999999).

Fortunately, Carbon provides the startOfDay() and endOfDay() methods that do just that :

$startDate = Carbon::createFromFormat('Y-m-d', '2021-06-01')->startOfDay();
$endDate = Carbon::createFromFormat('Y-m-d', '2021-06-30')->endOfDay();

$posts = Post::whereBetween('created_at', [$startDate, $endDate])->get();

Now that's much better, we can be pretty sure that everything created on the 1st or the 30th will be retrieved no matter what time they were created at or what time it is.

It's a solid solution and you can definitely use it, but adding a time when really we only care about the date feels a tiny bit like a hack to me, so let's see another solution

Another way with MySQL

We could also explicitly tell MySQL that we only care about the date by using DATE(). The query we want is this :

SELECT * FROM posts
  WHERE DATE(created_at) BETWEEN '2021-06-01' AND '2021-06-30'

That way we'll compare dates with dates, and not with a Datetime. We'll need to resort to DB:raw() to replicate this with Eloquent, which would look like this :

$startDate = '2021-06-01';
$endDate = '2021-06-30';

Post::whereBetween(DB::raw('DATE(created_at)'), [$startDate, $endDate])->get();

Ideally we should make sure that $startDate and $endDate are properly formatted as dates, but it seems to work even if we pass a full Carbon object (which is automatically converted to a string) as MySQL will ignore the time portion.

So that's another way to do it, but I'm not a fan of using DB::raw() either, plus it could be slower (more about that in the last paragraph). So let's see a final solution that leverages Eloquent to handle that.

Yet another way with Eloquent

Eloquent provides a very helpful whereDate() method that will do two things

Build an SQL query that uses the DATE() SQL function to format the content of the column as Y-m-d.
Properly cast a Carbon or Datetime object to the Y-m-d format before comparing it.

Using this, we can confidently pass Carbon instances and know that any time that happens to be a part of it will be discarded and we'll actually be searching between two dates :

$startDate = Carbon::createFromFormat('Y-m-d', '2021-06-01');
$endDate = Carbon::createFromFormat('Y-m-d', '2021-06-30');

$posts = Post::query()
    ->whereDate('created_at', '>=', $startDate)
    ->whereDate('created_at', '<=', $endDate)
    ->get();

This will generate this SQL query :

SELECT * from "posts"
WHERE DATE("created_at") >= '2021-06-01'
AND DATE("created_at") <= '2021-06-30';

And it works flawlessly. The only downside is that we can't use between so it's a little bit longer to write, but if we're going to use it in several places we could easily write a scope (and maybe even make it generic so that it could be imported as a Trait in every model that needs it ?), something like that :

public function scopeCreatedBetweenDates($query, array $dates)
{
    return $query->whereDate('created_at', '>=', $dates[0])
        ->whereDate('created_at', '<=', $dates[1])
}

And use it instead :

$startDate = Carbon::createFromFormat('Y-m-d', '2021-06-01');
$endDate   = Carbon::createFromFormat('Y-m-d', '2021-06-30');

$posts = Post::createdBetweenDates([$startDate, $endDate])->get();

Now that looks pretty good to me ! Unfortunately it might not be the fastest solution...

What about performance ?

Note : This was not part of the original article, and someone on Linkedin asked me "what about performance"... Which opened a whole new can of worms I hadn't really anticipated (which Oliver also pointed out in the comments).

All of the approaches above have about the same performance if you don't have any index on the created_at column, which is probably fine if you need to filter a few dozens or hundreds of models by date, but if you start working with a lot more than that you'll need to create an index and... Things get messy.

If you create a simple index on the created_at column, the Carbon approach that uses ->startOfDay(), ->endOfDay() and ->between() will be a lot faster because it can leverage the index.

Unfortunately anything that involves the DATE() function, either by using DB::raw() or Laravel's WhereDate() function won't be able to use that index because it contains the timestamp.

The theoretical solution to this is to create a functional index on DATE(created_at)in MySQL. There are two caveats though :

Functional indexes are only available on MySQL 8.0.13 and above
For some reason that I can't figure out, the functional index is not used when using prepared statements. So in order for it to work you'd have to also use PDO's emulated prepared statements which is not the recommended way.

So all in all, my final recommendation is to stick with Carbon to get the start and end of day. And we can still use a scope for that to make it easier to use (we'll also make it accept either a Carbon instance or a string) :

public function scopeCreatedBetweenDates($query, array $dates)
{
    $start = ($dates[0] instanceof Carbon) ? $dates[0] : Carbon::parse($dates[0]);
    $end   = ($dates[1] instanceof Carbon) ? $dates[1] : Carbon::parse($dates[1]);

    return $query->whereBetween('created_at', [
        $start->startOfDay(),
        $end->endOfDay()
    ]);
}

And we can use it like so :

$posts = Post::createdBetweenDates(['2021-06-01', '2021-06-30'])->get();

Conclusion

Dealing with time is hard. I find that when dealing with dates and time, even if it looks simple, it pays to take an extra minute to wonder if it really is that simple and if you're not missing something (and we haven't even touched time zones, Daylight Saving Time, and leap seconds...)

Anything I missed ? Questions ? Horror stories to share about dates ? hit the comments !

How the new 'One Of Many' Laravel relationship made my project 600 times faster

Nicolus — Fri, 21 May 2021 11:31:51 +0000

When a framework is as mature as Laravel, most new features tend to become subtle improvements, "nice to haves", or something that covers an edge case that you might encounter someday... But sometimes there's a feature that makes you think "That's what I've been waiting for !".

That's precisely what happened to me when the 'One Of Many' relationships was added to Laravel 8.42 a few days ago. And I'm pretty sure I'm not the only one since it solves a pretty common problem : getting the latest item out of a One To Many relationship.

For example maybe you have a table where you write each time a user logs-in, and you want to get their latest login ? Or maybe an object that has to go through several steps in a workflow and you want to get its current status ? How convenient would it be to be able to just call $user->latestLogin() or $order->currentStatus() ?

until now it was of course doable, but it was either really tedious or had a very high performance impact. Let me give you an example

My Monitoring app

One of my current pet projects is a very simple monitoring app, that allows a user to enter a few URLs that the service will "ping" every minute, and send a text message if it becomes unavailable. The main (and only) page looks like this :

I have a grand total of 3 models in the app :

User : A Laravel user
Url : A URL to monitor (a user can have many URLs)
Check : A check that was made on a URL (a URL has many checks)

The controller for this view is really simple and the most simple approach would be something like that :

public function index(Request $request)
{
    $urls = auth()->user()->urls()->get();
    return response()->view('urls.index', ['urls' => $urls]);
}

And then in the view we create a table with each row looking like this :

@foreach($urls as $url)
    <tr>
        <td>{{ $url->name }}</td>
        <td>{{ $url->url }}</td>
        <td>{{ $url->latestCheck?->status }}</td>
    </tr>
@endforeach

And of course, I need to make latestCheck a relationship that can be queried, so I just added it in my URL model like so :

public function latestCheck(): HasOne
{
    return $this->hasOne(Check::class)->latest('id');
}

That works.

Well it kind of works. We have our results but we also have an issue called the "n+1 queries" problem, because every time we call latestCheck in the view, it will actually trigger an SQL query to get the latest check for that URL. It's very obvious when using Clockwork :

As you can see, we have 10 URLS to monitor so we make 10 SELECT queries on the checks table, but if we had 100 we'd have 100 queries which would be significantly slower. Even as it is the page takes 600ms to load which is way too long for something simple as that.

Note : The subsequent queries are faster and faster. That's because for this test I seeded the checks for each URL one after the other, so the checks for the 10th URL will be higher in the table, and be found much faster. That's not really what would happen in production.

Eager loading to the rescue !

Luckily Laravel provides us with a way to avoid this "n+1 queries" problem : eager loading. We can tell it to load all the elements of a relationships in one query by using the ->with() method like so :

$urls = auth()->user()->urls()->with('latestCheck')->get();

And sure enough, we now have only one query :

And now our page displays in... WHAAAAAAT ? 20 seconds ? And it's using 480MB of memory ? that can't be right. What's happening ?

Looking at the query, it doesn't seem to have any kind of "LIMIT" statement :

SELECT * FROM `checks` WHERE `checks`.`url_id` in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) ORDER BY `id` DESC

This will fetch ALL of the checks for those 10 URLS, and apparently Laravel is then working on a collection to extract the first check from each URL, except in my case it's a collection of 500000 items so it takes a lot of time and a lot of memory. So in our case it turns out that eager loading is actually much slower than lazy loading.

This is very unsatisfying but going back to lazy loading was our best option with Eloquent prior to Laravel 8.42. If we wanted better performance the only other way was to ditch Eloquent and write our own query with JOIN and MAX() to get the latest check.

LatestOfMany Relationship to the Rescue !

Fortunately we now have a much better solution, we can just rewrite that relationship with a small change :

public function latestCheck()
{
    return $this->hasOne(Check::class)->latestOfMany();
}

We replaced latest() with latestOfMany(), and now Laravel will make the proper SQL query behind the scene :

Now that's much better ! We went from 600ms (or 20000ms with eager loading) to less than 30ms (which is over 600 times faster than the worst case scenario), and we do have only one query that fetches just what we need :

EXPLAIN SELECT * FROM `checks`
  inner join (
    SELECT MAX(id) as id, `checks`.`url_id` FROM `checks`
    GROUP BY `checks`.`url_id`
  ) as `latestCheck`
  on `latestCheck`.`id` = `checks`.`id`
  and `latestCheck`.`url_id` = `checks`.`url_id`
WHERE `checks`.`url_id` in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10)

That's really not something I'd want to write in raw SQL or the Query Builder if I don't have to, so it's really nice to have it available in one method !

Conclusion

That's all there is to it really. Whenever you want the latest occurrence of a relationship you can use this new method and it will automatically be much faster while keeping your code clean and readable !

Let us know if you've had similar experiences, or maybe a more original use case for these new relationships ?

Laravel Fortify : Implement 2FA in a way that won't let users lock themselves out

Nicolus — Mon, 17 May 2021 11:21:05 +0000

The problem with Fortify and Two Factor Authentication

Laravel Fortify is pretty awesome. It handles most of the heavy lifting of authentication for you, but unlike Laravel Breeze (which publishes Controllers and views in your application) or Laravel Jetstream (which actually uses Fortify behind the scenes), it lets you in charge of creating your own views so you don't have to use tailwind CSS or inertia.js.

One of the things it handles and was very appealing to me is Two Factor Authentication (2FA) with Time-Based One Time Passwords (TOTP) : The thing that asks you to scan a QR code in an application like Google Authenticator or Duo, and then gives you a new 6 character password every 30 seconds that you have to enter to log-in.

That's really nice because it's an essential feature for any application that need decent security, and I wouldn't know where to start if I had to implement it from scratch. But as of now it has one major limitation : If you implement it by following the documentation to the letter, there's a good chance that your users will end up locked out of your app when they try to enable it. The issue is described in detail here, but it boils down to the fact that Fortify won't ask for the user to enter a code to confirm that they successfully installed the app and scanned the QR code, so if they activate 2FA and then fail to add your site to Google Authenticator (or their computer crashes or something), they wont be able to log into your site ever again.

Thankfully, Laravel is flexible enough that with a little work we can implement our own confirmation system while still leveraging all the goodies that Fortify gives us.

The solution

The solution we'll be implementing is pretty common : Once a user activates 2FA, instead of simply enabling it, displaying the QR code once and calling it a day, we'll show the QR code, ask them to enter a TOTP generated with Google Authenticator to confirm they did everything correctly, and only then activate 2FA.

You can find a working example of what we'll do on this github repository (keep in mind that it's just an example, you'd probably do things a bit differently in a real world app).

Before we'll start I'll assume that you already installed Fortify and implemented 2FA following the official documentation.

So let's dig in !

Step 1 : Add a new 'two_factor_confirmed' field

Fortify comes with a migration that adds the two_factor_secret and two_factor_recovery_codes columns to the users table. Whenever a user activates 2FA (by POSTing to the /user/two-factor-authentication endpoint) these fields get populated, and that's how Laravel knows it needs to ask for a TOTP when the user tries to login.

Since we want the user to confirm that they have setup everything correctly, we need a new column to store that confirmation. To that end, we'll create a new migration that creates that column, the up() method will look like that :

    Schema::table('users', function (Blueprint $table) {
        $table->boolean('two_factor_confirmed')
            ->after('two_factor_recovery_codes')
            ->default(false);
    });

Now we probably have a view that displays either a button to enable 2FA, or the QR code when the user gets back to it after enabling 2FA. It's likely a variation of something like this :

<!-- 2FA enabled, we display the QR code : -->        
@if(auth()->user()->two_factor_secret)
    {!! auth()->user()->twoFactorQrCodeSvg() !!}
<!-- 2FA not enabled, we show an 'enable' button  : -->
@else
    <form action="/user/two-factor-authentication" method="post">
        @csrf
        <button type="submit">Activate 2FA</button>
    </form>
@endif

At this point, we should be able to modify the two_factor_confirmed column in the database and it will change what we display on the page.

There are still two major issues though :

We don't have a way to update our new column
Laravel itself doesn't care about it, and will keep asking the user for a TOTP as soon as the two_factor_secret column is filled.

Step 2 : Update the column when the User confirms 2FA

First we'll need a route on which we'll POST a TOTP to confirm that the user is able to get one. So let's add it to our routes/web.php file, along with a corresponding TwoFactorAuthController

/routes/web.php :

Route::post('/2fa-confirm', [TwoFactorAuthController::class, 'confirm'])->name('two-factor.confirm');

Now we could handle the verification and update directly in the Controller, but I think it makes more sense to let the User model do it, so the confirm() method of our Controller will only tell the User to check the TOTP provided in the code parameter, and then redirect back (with an error if the code was not valid).

/app/Http/Controllers/TwoFactorAuthController :

public function confirm(Request $request)
{
    $confirmed = $request->user()->confirmTwoFactorAuth($request->code);

    if (!$confirmed) {
        return back()->withErrors('Invalid Two Factor Authentication code');
    }

    return back();
}

And finally we add the confirmTwoFactorAuth() method in our User model.

/app/Models/User :

public function confirmTwoFactorAuth($code)
{
    $codeIsValid = app(TwoFactorAuthenticationProvider::class)
        ->verify(decrypt($this->two_factor_secret), $code);

     if ($codeIsValid) {
        $this->two_factor_confirmed = true;
        $this->save();

        return true;
    }

    return false;
}

Now we can update our main view to either :

Display the "Activate 2FA" button if it's not enabled at all
Display the QR Code and a form that POSTs to the route we just created if it's enabled but not confirmed
Display a button that will disable 2FA by sending a DELETE request.

/resources/views/home.blade.php :

<!-- 2FA confirmed, we show a 'disable' button to disable it : -->        
@if(auth()->user()->two_factor_confirmed)
    <form action="/user/two-factor-authentication" method="post">
        @csrf
        @method('delete')
        <button type="submit">Disable 2FA</button>
    </form>
<!-- 2FA enabled but not yet confirmed, we show the QRcode and ask for confirmation : -->
@elseif(auth()->user()->two_factor_secret)
    <p>Validate 2FA by scanning the floowing QRcode and entering the TOTP</p>
    {!! auth()->user()->twoFactorQrCodeSvg() !!}
    <form action="{{route('two-factor.confirm')}}" method="post">
        @csrf
        <input name="code" required/>
        <button type="submit">Validate 2FA</button>
    </form>
</div>
<!-- 2FA not enabled at all, we show an 'enable' button  : -->
@else
    <form action="/user/two-factor-authentication" method="post">
        @csrf
        <button type="submit">Activate 2FA</button>
    </form>
@endif

It should work well enough, so now the only problem remaining is that Fortify doesn't know about the two_factor_confirmed column and will keep asking for a TOTP.

Step 3 : check if the user has confirmed 2FA before asking for a TOTP

We can see how Fortify determines if it needs to ask for a TOTP in its RedirectIfTwoFactorAuthenticatable which has this code in the handle method :

if (optional($user)->two_factor_secret &&
    in_array(TwoFactorAuthenticatable::class, class_uses_recursive($user))) {
    return $this->twoFactorChallengeResponse($request, $user);
}

It seems if $user->two_factor_secret is not null the user will be redirected. So the solution is pretty easy : We just have to change this to say if (optional($user)->two_factor_confirmed instead, right ?

Well yeah, except this file is in Fortify itself (in the vendor directory) so we're definitely not going to modify it directly.

Our best bet would be to create our own version of RedirectIfTwoFactorAuthenticatable and slightly change its behavior. So let's create a RedirectIfTwoFactorConfirmed class that extends the original one.

app/Actions/Fortify/RedirectIfTwoFactorConfirmed :

namespace App\Actions\Fortify;

use Laravel\Fortify\Actions\RedirectIfTwoFactorAuthenticatable;
use Laravel\Fortify\TwoFactorAuthenticatable;

class RedirectIfTwoFactorConfirmed extends RedirectIfTwoFactorAuthenticatable
{
    public function handle($request, $next)
    {
        $user = $this->validateCredentials($request);

        if (optional($user)->two_factor_confirmed &&
            in_array(TwoFactorAuthenticatable::class, class_uses_recursive($user))) {
            return $this->twoFactorChallengeResponse($request, $user);
        }

        return $next($request);
    }
}

Looks good, now to teach Fortify that it needs to use our Action now, we need to customize the Authentication Pipeline by adding this in /app/Providers/FortifyServiceProvider :

Fortify::authenticateThrough(function(){
    return array_filter([
        config('fortify.limiters.login') ? null : EnsureLoginIsNotThrottled::class,

    Features::enabled(Features::twoFactorAuthentication()) ? RedirectIfTwoFactorConfirmed::class : null,
        AttemptToAuthenticate::class,
        PrepareAuthenticatedSession::class,
    ]);
});

Again it's identical to the default Pipeline, except we replaced RedirectIfTwoFactorAuthenticatable with RedirectIfTwoFactorConfirmed.

And that's it, our users now need to confirm that they can get a valid TOTP before 2FA is actually enabled and they can't lock themselves out of our app !

Or can they ?...

Well there's still an issue with our workflow : what happens when we hit that 'Disable 2FA' button and we send a DELETE request to the Fortify Controller ? Fortify will set the two_factor_secret field to null, but now that we've modified the Authentication Pipeline to check for two_factor_confirmed instead, we've introduced a new problem, and we'll keep asking for a TOTP even after the user has disabled 2FA.

Step 4 : set 'two_factor_confirmed' to false when we disable 2FA

I we go back to Fortify's source code, we can see that it sets both two_factor_secret and two_factor_recovery_codes to null in the DisableTwoFactorAuthentication Action :

$user->forceFill([
    'two_factor_secret' => null,
    'two_factor_recovery_codes' => null,
])->save();

So we'll just need to add our column there, but once again we certainly don't want to start modifying our vendor directory. And this time there isn't a façade that allows us to change the Pipeline for that.

Luckily, we can rely on the Service Container to help us inject our own version of this Action.

Let's look at how it's used in Fortify. It all happens in the TwoFactorAuthenticationController (the very same that handles the DELETE request) :

public function destroy(Request $request, DisableTwoFactorAuthentication $disable)
    {
        $disable($request->user());

        return $request->wantsJson()
                    ? new JsonResponse('', 200)
                    : back()->with('status', 'two-factor-authentication-disabled');
    }

There's our action, and it looks like instead of being hardcoded inside of the function, it's resolved through dependency injection and then called right away. That's awesome news because it means we just have to tell the Service Container "whenever someone asks for DisableTwoFactorAuthentication, just use our own version instead".

So first let's create our own version (it's very important that it extends the original or else the Service Container won't be able to resolve it) :

/app/Actions/Fortify/DisableTwoFactorAuthentication

namespace App\Actions\Fortify;

class DisableTwoFactorAuthentication extends \Laravel\Fortify\Actions\DisableTwoFactorAuthentication
{
    public function __invoke($user)
    {
        $user->forceFill([
            'two_factor_secret' => null,
            'two_factor_recovery_codes' => null,
            'two_factor_confirmed' => 0,
        ])->save();
    }
}

And then tell the Service Container to bind this new class to the parent one by adding this in app/Providers/FortifyServiceProvider:

$this->app->bind(Laravel\Fortify\Actions\DisableTwoFactorAuthentication::class, function(){
    return new App\Actions\Fortify\DisableTwoFactorAuthentication();
});

Aaaaaaaaaaaand that's it ! We should finally have a fully working 2FA implementation that won't let your users lock themselves out.

Wrapping things up

Looking at the wall of text and code above I realize it looks like a lot to take in, but it's really not that complicated, what we did was :

Add a new 'confirmed' column with a migration
Add a new route and controller to set that column to true
Extend the RedirectIfTwoFactorAuthenticatable action with our own that checks for that column instead of the 'two_factor_secret' one
Override the Authentication Pipeline to use our own action
Extend the DisableTwoFactorAuthentication Action with our own that disables the 'confirmed' column
Use the service container to bind our own action to DisableTwoFactorAuthentication.

Any question ? anything you would have done differently ? Post in the comments !

Laravel Sanctum Explained : SPA Authentication

Nicolus — Sun, 24 May 2020 15:35:35 +0000

This is going to be a multi-part article about Laravel Sanctum (previously known as "Airlock"), the new Laravel authentication system. I've played with Sanctum a lot in the last few weeks and it appeared to me that while the package itself works really well and does exactly what it says it does, there are A LOT of ways things could go wrong. And yes, it's almost always user error, but it can be incredibly hard to debug and find out what you missed unless you have a basic understanding of what's going on, which is what we'll try and get here.

Note that this is not a complete tutorial (that may come later), so you will still need to read the documentation along with this article

How sanctum works with Single Page applications

If you read the docs, you already know that Sanctum provides several authentication methods : API tokens, SPA Authentication, and Mobile application authentication. It boils down to two different approaches : Stateless authentication (without sessions) and Stateful authentication (with sessions).
When using a single page application that runs in the browser we want to use stateful authentication, because it only relies on a HttpOnly session cookie to identify the user, which cannot be stolen through an XSS attack. We could use stateless authentication (actually that's what most of us did before Sanctum was released, with Laravel Passport), but this gives you a bearer token that you have to store somewhere, and it usually end up in the LocalStorage or a regular cookie that can be stolen through an XSS injection.

Things to know before you start

Most of this is in the docs, but it's really important so I'll summarize here :

Both your SPA and your API must share the same top-level domain. They can be on different subdomains though. For example you could have your front-end SPA on mydomain.com and the API on api.mydomain.com, or ui.mydomain.com and api.mydomain.com. But you cannot have on on mydomain.com and another on anothercomain.com. It simply won't work because the login request will come from your SPA, and the browser will not allow the backend to set a cookie for a different domain.
You must declare the domain of your SPA as "stateful" in the sanctum configuration file. This is because Sanctum uses a Middleware to force requests from your SPA to be considered as stateful (which is to say it will start a session for those requests). If you forgot to do it or change the domain of your SPA Laravel will not even try to use a session and nothing will work
CORS is a pain. Luckily Laravel 7 provides a CORS middleware out of the box, but by default it's configured (in the config/cors.php file) to only apply to routes starting with /api/*, you need to either change this to * or add every path your SPA will call like /login/ or /sanctum/csrf-cookie.

The whole Process

So here's a diagram of what happens when your SPA authenticates to your backend :

It's a little dense, but let's see what happens with each step :

1 : Getting a CSRF token

Although our cookies should be pretty safe, we still don't want to risk a malicious website tricking a user into logging in, so the login route (like all POST routes) is protected by a CSRF token. In a typical page with a form the token is served with the form and injected in a hidden field, but of course our SPA cannot do that, so we'll have to get it manually. Sanctum provides a /sanctum/csrf-cookie route that generates a CSRF token and return it, so the very first thing we need our SPA to do is make a GET request on that route

1a : Dealing with CORS

Since our frontend and backend are on two different subdomains, there's no way the browser will let us make some ajax request without some kind of verification, so the first thing that happens is that it makes an OPTIONS request. If everything is configured correctly, the HandleCors middleware will intercept the request and anwser with the correct authorization headers.

If you notice that your SPA sends an OPTIONS request and never tries to send a GET request look no further, your CORS settings are not properly configured.

1b : retrieving the CSRF cookie

After dealing with CORS the GET request will actually go through, and Sanctum will return the csrf token. Or rather it will return an empty page with an XSRF-TOKEN cookie.
This cookie is not supposed to be used as-is, what your SPA should do is read it, and then put its content into an X-XSRF-TOKEN header when it makes a POST request to login. This is a convention that's used by several frameworks and libraries including Axios and Angular, but you can also do it yourself. Note that Angular is a little picky about this header.

2 : Loggin in

Now we can log-in. Once again the HandleCors middleware will do its magic, and then the EnsureFrontEndRequestsAreStateful Middleware will (as its long name implies) make sure the request creates and uses a new session. This middleware will only be triggered if the domain name of your SPA is listed in the SANCTUM_STATEFUL_DOMAINS variable of your .env file, so make sure it's correctly configured.

If everything works, a new session will be created and the corresponding cookie will be returned.

Note that the cookie will be set to the domain declared in the SESSION_DOMAIN of your .env file, which should be your top-level domain preceded by a .. So if you use mydomain.com and api.mydomain.com you want to set the SESSION_DOMAIN to .mydomain.com so that both subdomains will be allowed to access it.

Also, the documentation recommends you use scaffolding, but it seems to me that it defeats the purpose of making an SPA. You don't want your typical redirect to /home either, so you can make your own LoginController with a very simple login method like that :

    public function login(Request $request)
    {
        if (Auth::attempt($request->only(['email', 'password']))) {
            return response(["success" => true], 200);
        } else {
            return response(["success" => false], 403);
        }
    }

3 : making requests to your app

From there on, you're SPA is connected like any stateful application. You can use the sanctum guard to protect routes and it will check that the user of the SPA is correctly authenticated.

That's it ! I hope this can be useful to someone. In the next weeks I'll do a complete write-up on how to use Sanctum with an Angular SPA, and with an Ionic App.

Also if you have any trouble with Sanctum, feel free to leave a comment and I'll try to help !

Closing a modal with the back button in Ionic 5 / Angular 9

Nicolus — Sun, 17 May 2020 16:37:36 +0000

I'm going to share this because it took me a couple hours of research and experimenting to achieve something that in my opinion should be the default behavior.

The issue :

So let's say you want to use a modal to display some information in your Ionic PWA (In my case I was displaying a list of articles, and I wanted to display the full article in a modal so as to not completely change page). You probably have a "back" or "cancel" button somewhere in your modal, and if your screen is big enough to see the rest of the page behind you can click that to dismiss the modal. So far so good !

Now the problem is that many users will want to use the hardware back button on their mouse or their phone to dismiss the modal (especially on a small screen where the modal takes the whole screen and looks like a new page), and in that case the default behavior is that it will change the actual page that's still behind your modal to the previous page... Which is definitely not what you would expect to happen.

The solution :

From Angular's perspective it makes sense : As far as the router component is concerned you never changed page (you just put a huge popup in front of your page), and hitting back will just bring you to the previous page... So let's change that !

1. Dismiss the Pop-up when the back button is pressed

This can be done easily with the @HostListener() decorator, which allows you to listen for a DOM event and trigger the decorated method when it happens. So in our modal component we can listen for the history popState and dismiss our modal :

  @HostListener('window:popstate', ['$event'])
  dismissModal() {
    this.modalController.dismiss();
  }

Chances are you already have a method that dismisses your modal that you may call from a "cancel" or "close" button in your html. If that's the case you don't need to create a new method, you can just add the decorator to your existing method.

That should work great for dismissing the modal, except won't prevent the back button from also going back in the history and switch to the previous page.

2. Don't go back to the previous page after dismissing the modal

Unfortunately there doesn't seem to be a way to prevent the default behavior of the back button, so we'll need to be get clever. One solution is to push a "fake" state for our modal in the history when it's displayed, that way the popState event will just get rid of that fake state. We can put anything we want in the "state" parameter of history.pushState(), so we'll put a modal boolean in case we later need to check if a specific state was created for a modal. Let's so it in our ngOnInit method :

  ngOnInit() {
      const modalState = {
          modal : true,
          desc : 'fake state for our modal'
      };
      history.pushState(modalState, null);
  }

This is good. But there's still a tiny little problem : What happens if the user dismisses the modal without using the back button (by clicking on the close button in the modal itself, or clicking outside of the modal) ? We're left with a phantom state in our history and the next time they press back nothing will happen !

3. Remove any phantom history when the modal is dismissed

We'll need to manually cleanup the history in this case. So let's use our modal to remove the last state if needed when we dismiss our modal in the
ngDestroy() method :

  ngOnDestroy() {
    if (window.history.state.modal) {
      history.back();
    }
  }

And NOW we're good to go. We should have covered all cases and it will give the perfect illusion that you can dismiss a popup with the back button !

Here's the whole component with the constructor and our 3 methods :

import { Component, HostListener, OnDestroy, OnInit } from '@angular/core';
import { ModalController } from '@ionic/angular';

@Component({
  selector: 'app-mymodal',
  templateUrl: './mymodal.page.html',
  styleUrls: ['./mymodal.page.scss'],
})
export class MyModalComponent implements OnInit, OnDestroy {

  constructor(
    private modalController: ModalController) {
  }

  ngOnInit() {
    const modalState = {
      modal : true,
      desc : 'fake state for our modal'
    };
    history.pushState(modalState, null);
  }

  ngOnDestroy() {
    if (window.history.state.modal) {
      history.back();
    }
  }

  @HostListener('window:popstate', ['$event'])
  dismissModal() {
    this.modalController.dismiss();
  }

}

Thanks for reading ! So far it seems to work fine for me but let me know if I missed anything or if you have another solution.

References :

Sprint charts : Burn down or Burn up ?

Nicolus — Sun, 21 Jul 2019 13:54:30 +0000

So my team has been working with Scrum (or at least some scrum-inspired in-house methodology) for a few month now, and I realize that I'm not entirely satisfied with the Burn down charts that gitlab (or most other tools) is providing us. I feel they don't always tell the whole story.

I found that burn up charts are a lot more interesting, but I don't see many people using them. So maybe it's just me ? Or maybe we're not planning the way we should ? Let me explain my point and tell me what you think in the comments !

The "Ideal" Sprint

An ideal sprint : burn down chart on the left, burn up on the right

Let's consider a pretty perfect sprint above. We determined our team velocity and estimated that as a team we could tackle about 100 points a week. Then during sprint planning we estimated some tasks and put 100 points worth of tasks in our sprint. In this example it worked really well and we were able to complete all the tasks in time at a very steady rate, yay !

Here the two charts are not really that different : The burn down chart on the left starts at 100 points in the upper left corner with the red line representing the number of tasks (or rather points) left to complete, and the goal is to bring it down by following the dashed grey line as closely as possible. The burn up chart is working the other way : The blue line at the top represents the number of points to complete, and the aim is to complete them all and bring the red line up.

In this ideal scenario there's no real advantage to a burn up chart, but honestly I have yet to see a chart that looks like this in our team, so let's move on to other scenarios

The "Can we just add this tiny task ?" Sprint

A sprint where we added a task : burndown chart on the left, burn up on the right

That's when things start to go South. In each an everyone of our sprints there's always something that we did not anticipate and that we just have to deal with. So naturally we add a task to the sprint and we try to handle it the best we can. Sometimes it works out, and sometimes it doesn't.

In this case it didn't quite work out as we can see on the charts. But what's interesting is that by looking at the traditional burn down chart we don't know what happened. It just looks like for some reason the team got less productive towards the end of the sprint (which can indeed happen if we hit a roadblock). The burn up chart is a lot more interesting here because we clearly see that the team handled exactly the amount of work that was planned, but we missed our objective because we had to add on to that.

The "Maybe we don't need that" Sprint

A sprint where we removed a tasks : burndown chart on the left, burn up on the right

This is the opposite of the previous example : At some point during the sprint something was dropped. Maybe we had to wait for something external to the team and decided to move it to a future sprint, or someone changed their mind about a feature, or maybe we just realized we were late on that sprint and decided to cheat a little and remove less critical tasks...

Anyway, the result is that with a burn down chart everything looks fine : We completed our 100 points ! But once again the burn up chart shows the whole story, and we clearly see that we only did 80 points worth of tasks.

Why does it matter ?

As we saw from the examples, Burn up charts only make a difference when tasks are added or removed mid sprint, so if this never happens in your team it won't make much of a difference. If that's the kind of things that does happen, it can give you a better view of what actually happened.

The goal here is not to put the blame on someone when expectations aren't met, but simply to be able to better adjust our velocity for the next sprints and get more efficient as a team. I feel that if we can better visualize what went wrong (or right), we'll be able to better plan the next sprints.

So what do you think ? Are burn down charts just fine, or is it better to use burn up charts ? Or do you have a completely different way of evaluating a sprint ?

What you should know about CORS

Nicolus — Sun, 14 Jul 2019 17:11:59 +0000

If you're anything like me, the first time you encountered CORS (or Cross-origin resource sharing), all you wanted was for your server to accept those darn ajax requests and be done with it. So you went to stack overflow, copy pasted a code snippet to set some headers, and it worked.

There are however a few things you might want to know.

What CORS is, and what it is not

This is often a source of confusion for newcomers because it's not immediately apparent what CORS is supposed achieve. Firstly CORS is not a security measure in itself, it's actually the opposite: CORS is a way to circumvent the "Same Origin Policy" which is the security measure preventing you from making ajax requests to a different domain.

The Same Origin Policy states that a website on one domain cannot make an xhr request to another domain. This prevents a malicious website from making requests to a known website (think Facebook or Google) hoping the user are already logged-in so that it can impersonate them.
This policy is implemented by the browser (all of them implement SOP, although there are minor differences), which means that it won't apply to requests made from a server, or any other HTTP clients like cURL or POSTman. Also the server has absolutely no control over this : it will process every request as if it was coming from a trusted domain, it is entirely up to the browser to block the requests.

SOP is in no way meant to prevent an attacker from making requests to your server (since an attacker would obviously not use a browser). It's only meant to prevent legitimate users using a reputable browser from unknowingly making requests to your website.

Now CORS are a way to bypass SOP in some cases where you want to allow one specific website to make requests to your server, even though it would normally be blocked. (typically, to allow your front-end app to make requests to your API).

How CORS work.

CORS, like the rest of HTTP is basically a dialogue between the browser and the server. Assuming your front-end is on domain-a.com and your API on Domain-b.com, it would go something like this :

  -Browser : "Hey Domain-B, this script on Domain-A.com is asking me to make an ajax query to you, but I'm supposed to block it unless you tell me it's OK."
  -Server : "I don't know, but I can tell you that only https://domain-a.com is allowed to make GET, POST, OPTIONS and DELETE requests, and this needs to be validated every 10 minutes.
  Browser thinks to himself "yeah, that's the right domain, I'll send the request !"
  -Browser : "Hey domain-b, I'd like to POST on this endpoint please.
  -Server : Sure thing, here's a 200

Or if the user is on a different domain the dialogue would be shorter, and look like that :

  -Browser : "Hey domain-b.com, this script on malicious-domain.com is asking me to make an ajax query to you, but I'm supposed to block it unless you tell me it's OK."
  -Server : "I don't know, but I can tell you that only https://domain-a.com is allowed to make GET, POST, OPTIONS and DELETE requests, and this needs to be validated every 10 minutes.
  Browser thinks to himself "Oh it's not the right domain, we'd better not make that request" and proceeds to send an error in the console.

How it looks in the browser

In my little scenes above, the first question from the browser is called a Preflight request, and the corresponding HTTP verb is OPTIONS. The server should always answer to Preflight Requests with a 200 response that has no body but contains the Access-Control-Allow-Origin and a few other headers. In our example the headers would be :



HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://domain-a.com
Access-Control-Allow-Methods: GET, POST, OPTIONS, DELETE
Access-Control-Max-Age: 3600

It tells the browser that it can only perform the request if it comes from domain-A.com, that it can only make GET, POST, OPTIONS or DELETE requests (a PUT request would be blocked for example), and that it can cache this information for 3600 seconds so it doesn't need to make a new OPTIONS request every single time.

And of course, if we're on a different domain that won't work. The browser will send an OPTIONS request, throw an error in the console and never send the POST request :

Pretty straight forward, right ?

Well yes, except there are a few gotchas...

Tricky things about CORS

All Responses should contain the CORS headers

You might think that if your server answers to the OPTIONS request with a 200 and the right headers you're in the clear, and you'll see the browser send the OPTIONS request, then send your actual request, and then fail miserably... That's because every request (GET, POST, or otherwise) should also contain the same "Access-Control-Allow-Headers".

Not all requests will trigger a Preflight Request

There are a few requests that won't trigger a Preflight Request, for example GET requests, or POST request with with a Content-Type header set to application/x-www-form-urlencoded. Those are "simple requests" that have always been allowed by browsers (you've always been able to make a link or POST a form to a different website, even before CORS exsisted), and you can find the full list here.
in the case of a POST request the result is a little counter-intuitive : The browser will make the POST Request (so your server will likely persist some data), and then ignore the response !

In a traditional web app you'd use application/json as a content-type so there will be a preflight request, but keep in mind your server may still receive POST requests from other domains, so don't blindly accept them.

The allowed domain must include the protocol

You can't just put mydomain.com as a domain, it needs to include the protocol (eg. https://mydomain.com). The fun part is you can't really accept both http and https because...

You can only allow one domain

You can either allow every domain with Access-Control-Allow-Origin: *, or only one. This means that if you need several domains to access your api, you'll need to handle it yourself.

The easiest way to handle this is to maintain a list of allowed domains on your server, and change the content of the header dynamically if the domain is in that list. Here's how it would look in plain PHP for example :



$allowedDomains = [
    "http://www.mydomain.com",
    "https://www.mydomain.com",
    "http://www.myotherdomain.com",
    "http://www.myotherdomain.com",
];

$originDomain = $_SERVER['HTTP_ORIGIN'];

if (in_array($originDomain, $allowedDomains)) {
    header("Access-Control-Allow-Origin: $originDomain");
};

Or in Node.js (adapted from this SO anwser)



app.use(function(req, res, next) {

  const allowedOrigins = [

    "http://www.mydomain.com",

    "https://www.mydomain.com",

    "http://www.myotherdomain.com",

    "http://www.myotherdomain.com",

  ];

  const origin = req.headers.origin;

  if(allowedOrigins.indexOf(origin) > -1){

    res.setHeader('Access-Control-Allow-Origin', origin);

  }

  return next();

});

Same Origin Policy applies to the file system on Chrome and Safari, not on Firefox.

If you make a request to a local file, Firefox will consider that it's always on the same domain and allow the request. Webkit based browsers like Chrome or Safari will consider this a security risk and block ajax queries to local files. The only way to get around this is to either use Firefox, or install a web server that will send an Access-Control-Allow-Origin: * header.
As pointed out by @brianjenkins94 in the comments, you could also start Chrome with the --disable-web-security flag.

The iOS WKWebview needs CORS

If you're developing a mobile app that uses a webview (with Cordova or Ionic), Android won't give you any trouble, but the new WKWebview on iOS will require CORS. This means you pretty much have to always set the Access-Control-Allow-Origin header to *, which is really not ideal.
Another alternative is to not make ajax requests in your app and use a cordova plugin to make native http requests, which will happily ignore the Same origin Policy.

Thanks for reading !
If you want a more in depth description of CORS, head to MDN : https://developer.mozilla.org/docs/Web/HTTP/CORS.

Getting Homestead to play nice with Hyper-V

Nicolus — Sat, 02 Feb 2019 08:16:45 +0000

Homestead is a fantastic tool for local development. It's basically a preconfigured Ubuntu Vagrant box that already has everything you'd want for PHP development and more.
The most straightforward way to use it is to install Virtualbox. So if you don't need Hyper-V you can safely stop reading this post and be on your merry way.

However if you're like me, you may need it to run on Hyper-V instead of Virtualbox, because you can't have both running at the same time on Windows. So if you want to use Docker (which uses Hyper-V) or a Hyper-V machine for something else, it means you'll have to reboot your machine each time you want to use one or the other, which is really not practical.
The good news is that Homestead's support for Hyper-V has made a lot of progress in the past couple of years, but there are still a lot of gotchas that I'll try and go through here.

This was going to be a complete guide, but I figured that the official docs should be enough to get you started, so I'll just cover the specific issues I encountered when running Homestead with hyper-V.

Use everything as administrator

The first annoying thing is that for Homestead (and the underlying Vagrant) to be able to share your work folders with SMB, you need to use them as an administrator. Which in turn means that your IDE needs to be run as administrator to communicate with Homestead.

So you'll probably want to create shortcuts to start Powershell (or CMD) and your IDE as administrator and get into the habit of using those.

Set up the network

The main issue with this setup is that Vagrant is not (yet ?) able to manage Hyper-V's virtual switches, so you'll have to create one yourself or you won't be able to access both the internet and your own host machine from homestead.
To do so, open hyper-V manager, select Virtual Switch Manager in the Actions pane, click on New virtual Network Switch, and click on the create button. Give it a useful name (like "External Switch"), make sure External network is checked and the physical Ethernet controller that's connected to your network and the internet is selected, then click OK.

The first time Homestead starts, it should ask you which network to use, and you'll tell it to use this External Switch.

Automatically manage the host file

Through the vagrant-hostmanager plugin, homestead is able to automatically update your hosts file to make the domains you declare in Homestead.yaml accessible.
This is particularly useful with Hyper-V because the IP of your machine might change whenever you restart it, so without this plugin you'd need to go and edit your hosts file manually each time. Assuming Vagrant is installed you can install the plugin by running vagrant plugin install vagrant-hostmanager from anywhere in the command line.

From now on, each time your homestead starts your hosts file will be automagically updated so that all the domains declared in the Homestead.yaml file will point to your virtual machine. There are two things to keep in mind :

The plugin only triggers on vagrant up, not on vagrant reload, so when you restart your homestead machine you should always run vagrant halt then vagrant up to make sure your hosts are kept up to date
This only works because in this scenario we have to run vagrant as administrator so it has write access to the hosts file.

Allow Homestead to access your work folders

Homestead uses SMB to share files between your machine and the virtual machine when using Hyper-V. By default, it will ask for your login and password each time it starts up, which quickly becomes annoying.
Fortunately, you can now specify credentials to use for SMB shares directly in the Homestead.yaml file, but I wouldn't recommend putting your own credentials in plain sight in a file on your computer. What I found to be an acceptable solution was to :

Create a new windows user names "vagrant" with the password "vagrant".
Share my code folder (and every folder declared in the Homestead.yaml file) with this user and give it read/write permissions
Use the "vagrant" user credentials for each folder in the Homestead.yaml file like so :

folders:
    - map: ~/code
      to: /home/vagrant/code
      smb_username: vagrant
      smb_password: vagrant

Get x-debug to work from the command-line

X-debug should work out of the box to debug web pages, but it won't work from the command line with the provided xphp command. The reason is that this command assumes that your host machine's IP from the VM is 192.168.10.1, which is indeed the case with virtualbox, but not at all when running Hyper-v.
I found a solution to that, which is to modify the xphp alias so that it will find the last SSH connection to the VM, and use this IP as the remote_host for xdebug. It's probably not 100% reliable, but in most cases the IP should be your own since you'll be the only one to connect to the VM through ssh.
So what you'll need to do is edit the aliases file at the root of the Homestead directory, and replace the xphp() function with this one :

function xphp() {
    (php -m | grep -q xdebug)
    if [[ $? -eq 0 ]]
    then
        XDEBUG_ENABLED=true
    else
        XDEBUG_ENABLED=false
    fi

    if ! $XDEBUG_ENABLED; then xon; fi

    #Find the IP of the latest ssh connection :
    HOST_IP=$(last --limit=1 | grep -oP '\d+(\.\d+){3}')

    php \
        -dxdebug.remote_host=${HOST_IP} \
        -dxdebug.remote_autostart=1 \
        "$@"

    if ! $XDEBUG_ENABLED; then xoff; fi
}

That's it for today, I hope this can be of help to someone !