Chapters
-
Course Code
Subscribe to download the code!
Subscribe to download the code!
-
This Video
Subscribe to download the video!
Subscribe to download the video!
-
Subtitles
Subscribe to download the subtitles!
Subscribe to download the subtitles!
-
Course Script
Subscribe to download the script!
Subscribe to download the script!
Automatically Redirect Ajax Calls to /login
Scroll down to the script below, click on any sentence (including terminal blocks) to jump to that spot in the video!
Keep on Learning!
If you liked what you've learned so far, dive in! Subscribe to get access to this tutorial plus video, code and script downloads.
With a Subscription, click any sentence in the script to jump to that part of the video!
Login SubscribeAll sites that loads things via Ajax have one annoying problem: what happens if the user gets logged out due to inactivity? Obviously if the user gets logged out and clicks a link to navigate the whole page, that's no problem. They'll get redirected to the login page.
But go to a product page and scroll down to the review section. Pretend that I stop right here, go home for the day, eat a delicious dinner, watch Mystery Science Theater 3000 and come back to my computer tomorrow. During that time, my session has timed out. What would happen if I tried to submit this form - which submits into a turbo-frame
- without refreshing first?
Well... let's try it! I'm going to imitate this situation by opening the site in a new tab... and logging out. Back over in the first tab, clear the network requests and submit. Uh, that was weird.
In the network tools, you can see that it did submit to the reviews page. But then, because I'm not logged in, it redirected to the login page. In the console, we see our favorite error:
response has no matching
<turbo-frame id="product-review">
element.
That makes sense! The Ajax request redirected to the login page. And so, the frame system followed that redirect and then looked for a product-review
<turbo-frame>
on that page... which it obviously doesn't have.
So the user experience here is... not so great. But for any frames that have our data-turbo-form-redirect
attribute, this problem is already fixed thanks to the system we just built!
Check it out. Refresh... log back in and head to the admin section. Remember: this modal does have that attribute on it. So I'm going to repeat our experiment. In the other tab, refresh, then log out. Back on the first tab, when we open the modal, the <turbo-frame>
will try to make a request to a page that requires authentication. When we try it... awesome! It redirected the entire page to /login
! That's perfect!
Wrapping the Redirect Response to /login
So this problem is fixed in some places... but not everywhere. But we can make this work everywhere.
In TurboFrameRedirectSubscriber
, look at shouldWrapRedirect()
. Let's think: if this response is a redirect to the login page and if the request is happening inside a <turbo-frame>
, then we definitely know that we want to wrap the redirect so that our JavaScript redirects the whole page.
Start by checking to see if not $request->headers->get('Turbo-Frame')
. In this case, return false
. Adding this check was redundant before... because if you have the Turbo-Frame-Redirect
header then you definitely have this one. But now it's going to help us detect if we're in a frame and if the response is redirecting to the login page.
Grab the redirect location by saying $location = $response->headers->get('Location')
. Instead of checking to see if this equals /login
, let's be fancier and use the URL generator.
At the top of the class, add a __construct()
function with a UrlGeneratorInterface
argument... which is just a more hipster way to get the router service. I'll hit Alt + Enter and go to "Initialize properties" to create that property and set it.
Back down in the method, if $location
is equal to $this->urlGenerator->generate()
, passing this the name of our login route - app_login
- then return true
.
That's it! If the response is a redirect... and the request is happening inside of a frame... and we're redirecting to the login page... then that's a problem. That's going to break the frame. And so, we'll wrap the redirect with our fake redirect so that our JavaScript can navigate things.
Show Lines
|
// ... lines 1 - 10 |
class TurboFrameRedirectSubscriber implements EventSubscriberInterface | |
{ | |
private UrlGeneratorInterface $urlGenerator; | |
public function __construct(UrlGeneratorInterface $urlGenerator) | |
{ | |
$this->urlGenerator = $urlGenerator; | |
} | |
Show Lines
|
// ... lines 20 - 37 |
private function shouldWrapRedirect(Request $request, Response $response): bool | |
{ | |
if (!$response->isRedirection()) { | |
return false; | |
} | |
$location = $response->headers->get('Location'); | |
if ($location === $this->urlGenerator->generate('app_login')) { | |
return true; | |
} | |
return (bool) $request->headers->get('Turbo-Frame-Redirect'); | |
} | |
} |
Testing time! Log back in... go back to a product page, scroll down to the reviews, and then, in the other tab, refresh and log out.
Back in tab number 1, try to submit the review form. Beautiful! We are smoothly redirected to the login page! This problem just got solved for any <turbo-frame>
on our site.
Okay team! Enough with turbo frames! It's time to dive into part 3 of Turbo: Turbo Streams. This feature is probably the smallest of the three, but also the most fun to work with.
4 Comments
Yo @jmsche!
Sorry for the late reply. Why can this be skipped now? I think I missed some new Turbo feature - please tell me! :)
Cheers!
IIRC it automatically redirects to login page & there's no error in console.
LATE reply on this, but I was just trying the app on Turbo 7.3, and it still looks like it fails... which I think makes sense. When we make an Ajax request and its redirected to /login
, that's unfortunately "transparent" to JavaScript: they just get back the response and have no idea the redirect happened. So it "feels" like something that Turbo couldn't have fixed. But if you can remember what you were referring to, let me know!
Cheers!
"Houston: no signs of life"
Start the conversation!
What PHP libraries does this tutorial use?
// composer.json
{
"require": {
"php": ">=8.1",
"ext-ctype": "*",
"ext-iconv": "*",
"composer/package-versions-deprecated": "1.11.99.1", // 1.11.99.1
"doctrine/annotations": "^1.0", // 1.13.1
"doctrine/doctrine-bundle": "^2.2", // 2.3.2
"doctrine/orm": "^2.8", // 2.9.1
"phpdocumentor/reflection-docblock": "^5.2", // 5.2.2
"sensio/framework-extra-bundle": "^6.1", // v6.1.4
"symfony/asset": "5.3.*", // v5.3.0-RC1
"symfony/console": "5.3.*", // v5.3.0-RC1
"symfony/dotenv": "5.3.*", // v5.3.0-RC1
"symfony/flex": "^1.3.1", // v1.21.6
"symfony/form": "5.3.*", // v5.3.0-RC1
"symfony/framework-bundle": "5.3.*", // v5.3.0-RC1
"symfony/property-access": "5.3.*", // v5.3.0-RC1
"symfony/property-info": "5.3.*", // v5.3.0-RC1
"symfony/proxy-manager-bridge": "5.3.*", // v5.3.0-RC1
"symfony/runtime": "5.3.*", // v5.3.0-RC1
"symfony/security-bundle": "5.3.*", // v5.3.0-RC1
"symfony/serializer": "5.3.*", // v5.3.0-RC1
"symfony/twig-bundle": "5.3.*", // v5.3.0-RC1
"symfony/ux-chartjs": "^1.1", // v1.3.0
"symfony/ux-turbo": "^1.3", // v1.3.0
"symfony/ux-turbo-mercure": "^1.3", // v1.3.0
"symfony/validator": "5.3.*", // v5.3.0-RC1
"symfony/webpack-encore-bundle": "^1.9", // v1.11.2
"symfony/yaml": "5.3.*", // v5.3.0-RC1
"twig/extra-bundle": "^2.12|^3.0", // v3.3.1
"twig/intl-extra": "^3.2", // v3.3.0
"twig/string-extra": "^3.3", // v3.3.1
"twig/twig": "^2.12|^3.0" // v3.3.2
},
"require-dev": {
"doctrine/doctrine-fixtures-bundle": "^3.4", // 3.4.0
"symfony/debug-bundle": "^5.2", // v5.3.0-RC1
"symfony/maker-bundle": "^1.27", // v1.31.1
"symfony/monolog-bundle": "^3.0", // v3.7.0
"symfony/stopwatch": "^5.2", // v5.3.0-RC1
"symfony/var-dumper": "^5.2", // v5.3.0-RC1
"symfony/web-profiler-bundle": "^5.2", // v5.3.0-RC1
"zenstruck/foundry": "^1.10" // v1.10.0
}
}
What JavaScript libraries does this tutorial use?
// package.json
{
"devDependencies": {
"@babel/preset-react": "^7.0.0", // 7.13.13
"@fortawesome/fontawesome-free": "^5.15.3", // 5.15.3
"@hotwired/turbo": "^7.0.0-beta.5", // 1.2.6
"@popperjs/core": "^2.9.1", // 2.9.2
"@symfony/stimulus-bridge": "^2.0.0", // 2.1.0
"@symfony/ux-chartjs": "file:vendor/symfony/ux-chartjs/Resources/assets", // 1.1.0
"@symfony/ux-turbo": "file:vendor/symfony/ux-turbo/Resources/assets", // 0.1.0
"@symfony/ux-turbo-mercure": "file:vendor/symfony/ux-turbo-mercure/Resources/assets", // 0.1.0
"@symfony/webpack-encore": "^1.0.0", // 1.3.0
"bootstrap": "^5.0.0-beta2", // 5.0.1
"chart.js": "^2.9.4",
"core-js": "^3.0.0", // 3.13.0
"jquery": "^3.6.0", // 3.6.0
"react": "^17.0.1", // 17.0.2
"react-dom": "^17.0.1", // 17.0.2
"regenerator-runtime": "^0.13.2", // 0.13.7
"stimulus": "^2.0.0", // 2.0.0
"stimulus-autocomplete": "https://github.com/weaverryan/stimulus-autocomplete#toggle-event-always-dist", // 2.0.0
"stimulus-use": "^0.24.0-1", // 0.24.0-2
"sweetalert2": "^11.0.8", // 11.0.12
"webpack-bundle-analyzer": "^4.4.0", // 4.4.2
"webpack-notifier": "^1.6.0" // 1.13.0
}
}
I think this chapter can be skipped for users of a recent version of Turbo :)