modal-session-expired is not firing

Well the case 401 is already checking that for you! When your server returns a 401, it means the client is unauthorized. So that's when the popup should show!

Source: https://httpstatuses.com/401

I see that the code also fires a bit of jQuery code in here, or at least it kicks of the modal for the session. Are you sure jQuery is loaded? Also does your developer console show anything? You can test this by setting the session time really low for example. An alternative is just firing the modal in all cases, just to check!

window.axios.interceptors.response.use(function (response) {
    // On success fire modal
    $('#modal-session-expired').modal('show');

    return response;
}, function (error) {
    // On error fire modal
    $('#modal-session-expired').modal('show');

    return Promise.reject(error);
});

Thanks for the ideas. Here's what I've tried:

1. jQuery is loaded. When I fire the modal in all cases, and then navigate to a page, the modal pops up.
2. When I set the session time really low (1 minute), though, the modal doesn't fire when I perform an axios.post request. Instead of a 401 error, I get a 419 error instead of a 401 error. I assume this is the case because my CSRF token has expired because my session has expired.

But, because I do this within vue, the browser just sits there, not informing the user in any substantive way.

Perhaps I'm not quite doing this right. Or is there a better way to continually check for the 401 error so the 419 error doesn't happen?

Hi @brjohnson4 , I had the same issue. You can just add another check to that switch, case 419:, right under case 401. If you're only using Vue and not jQuery, I would suggest replacing that jQuery call with something like:

Bus.$emit('session-expired');

and handle that wherever you like (pop your own dialog).

Side note: Spark source is really nice for learning experience, but lacking as a product (this being a small issue among those I have found/reported). It's nowhere near as polished as Forge, for instance.

@mkarnicki Adding to the switch case 419 is a great suggestion, and something that I toyed around with yesterday to get around this issue. Just on the off chance that I had a token mismatch that I really wanted to log as a 419 (rather than treating it just like a 401), I decided instead to go into my Exceptions handler and added just the specific post routes that I was worried about. They would then redirect back to the original page, resulting in a real 401 error, thus firing the modal.

This bit of code is from App/Exceptions/Handler.php

    public function render($request, Exception $exception)
    {
       if ($exception instanceof \Illuminate\Session\TokenMismatchException 
            && ($request->path() == 'api/first-url' || $request->path() == 'api/second-url')
        ) {
           return redirect()
                  ->back();
       }

       return parent::render($request, $exception);
    }

Still, your solution is a good one, and worth making the correct answer, I think.

I agree with your side note. I've had several different instances of something interesting going on with Spark, and there's very little out there to help with these smaller questions.

I think everybody using spark is using jquery, since some of the spark js is using it in multiple places. They might not be using it to code "their" app, but spark uses it itself.