Quicklink not working with login functionality

[matoululu]

I'm encountering an issue when trying to implement quicklink on shopify store. After users login in they are brought to their account page as expected. Once they move to any new page they are no longer logged in. I've tried a few solutions I thought may work but to no avail.

I'm not sure if this is a limitation issue or not so any insight would be great.

[coliff]

Have you tried removing quicklink to see if that solves the logged in status issue? I don't think quicklink should interfere with your users cookies / logged in status so your issue may be unrelated to quicklink.

If issue only happens with using quicklink then you could perhaps set it to not run on the users account pages or ignore those pages https://github.com/GoogleChromeLabs/quicklink#custom-ignore-patterns

[matoululu]

Yep, removing quicklink solves the issues, I had also set up quicklink not run on those pages as you mentioned but the issue persisted unfortunately.

[benjaminsehl]

This is happening to me as well. Cookies were clearing immediately, breaking a lot of functionality on the site. Have had to remove Quicklinks for now. @matoululu; have you found a solution or cause?

[matoululu]

@benjaminsehl unfortunately I did not find a cause/solution we decided to try out instant.page instead which looks to be working

[addyosmani]

If someone experiencing this issue would be able to share a user flow where this is happening, I would be happy to find the root cause. As @coliff mentioned, the usual solution to this is disallowing pages where reauthentication happens (or a logout page).

instant.page doesn't use the same heuristics we do for autofetching links in viewport so you sadly miss out on those benefits if switching.

[matoululu]

@addyosmani The user flow was:

Navigate to login page -> successful login sends user to account page -> user navigates anywhere else on the site and is then logged out

[kuldeepkeshwar]

@matoululu

Navigate to login page -> successful login sends user to account page -> user navigates anywhere else on the site and is then logged out

do you have logout as anchor link?

[matoululu]

@kuldeepkeshwar Yeah, there is one on the account page.

Originally we did set quicklink up to ignore the account page so we wouldn't trigger that link at (or any link) on that page but we still encountered the issue.

[simensol]

I have the same issue. It happens occasionally. Here is a screenshot from Chrome when everything work as expected:

All text/html files are prefetched by Quicklink. However, most of the times prefetched pages which rely on cookies (requires user login) suddenly return 401, like upload and subscription below:

What is strange, is that both the demo and analysis files also rely on cookies (require user login).

Here is the server's log showing the server returning 401 for subscription and upload:

[04-Sep-2019 10:13:02 UTC] /demo: return 200 [04-Sep-2019 10:13:02 UTC] /analysis: return 200 [04-Sep-2019 10:13:02 UTC] /contact: return 200 [04-Sep-2019 10:13:02 UTC] /subscription: return 401 [04-Sep-2019 10:13:02 UTC] /about: return 200 [04-Sep-2019 10:13:02 UTC] /profile: return 200 [04-Sep-2019 10:13:02 UTC] /upload: return 401

When I navigate away from the current page, I have been signed out (the session has been cleared, although the cookie still exist in Chrome).

I have made sure the signout url is ignored by Quicklink using ignores: [uri => uri.includes('signout')].

[demianrenzulli]

Hi guys,

The first thing that came to my mind was that you might be unintentionally prefetching the logout page, but seems like that has been clarified already.

@simensol, @matoululu: if you are still experiencing this issue, would it be possible that you share a live URL where this might be happening? We don't need quicklink to be implemented in those URLs. We might be able to just inject it in the page to reproduce.

Some questions:

• The server logs don't show any response headers. Could you provide such information?
• Would it be possible that upload / demo pages require any headers that the prefetch request is not including?

Would be interesting to go deeper into this. Cheers.

[simensol]

Unfortunately, @demianrenzulli, I don't have the files anymore as I have removed quick link due to the issue above. But maybe @matoululu can help?

[demianrenzulli]

Hi @simensol, thanks for your reply.

Even in the case that you have removed the library from the site, it can still be possible to reproduce this issue, by injecting it in the page, to simulate the same behavior as if the library were implemented. To do that, you can open Chrome DevTools and paste the following code in the console:

(function() {
  var script = document.createElement( "script" )
  script.type = "text/javascript";
  script.onload = function() {
    quicklink.listen();
  };

  script.src = "https://unpkg.com/quicklink@2.0.0-alpha/dist/quicklink.umd.js";
  document.getElementsByTagName( "head" )[0].appendChild( script );
})();

So, if you guys want to give it another try, or prefer us to take a look, just let us know. We would only need the URL of the page for that.

Also, @matoululu: you're welcome to share any insights from your experience. Cheers.

[matoululu]

Hey @demianrenzulli given the nature of my dev store the themes hop around a lot but I am able to provide you with a preview link that lasts for 2 weeks so i'm hoping this will be sufficient for you to give it a go on: https://txm96ddhzlxe6e51-11648818.shopifypreview.com You should still be able to use it as you would a normal shop.

Thanks!

[demianrenzulli]

HI @matoululu, thanks for sharing the URL.

I went ahead and tested the site, and couldn't see any strange behavior, nor any unexpected response code inspecting the Network trace. My only observation, is that I saw URLs for /account/logout and /account/login that would need to be added to the list of URLs to ignore. I recall you've mentioned you had ignored those already, so perhaps it would be good to check if the RegExp you're using is correct (if links are not prefetch for those URLs, you are ignoring them correctly).

In my previous comment, I shared a way in which you can inject Quicklink with a script to test it in your site. Fortunately, there's an even easier way of testing this yourself, without implementing the library.

We've just released the Quicklink Chrome Extension. Once installed, the extension injects Quicklink in every site you visit. You can control the list of patterns to ignore, by clicking on the extension and going to "Options". By default, both login and logout are included in the list to ignore, so in the case of your site, I don't think you need to add anything else.

Once installed you can inspect the prefetched links in the Network tab of CDT (Priority=Lowest, Initiator=quicklink.umd.js).

That would give you an idea of how your site should behave when the library is implemented.

Perhaps you want to give it a try yourself and share your findings?

Cheers.

[simensol]

Hi again @demianrenzulli. I have now created an online test page available at easystat.com/quicklink. I have added some protected links to the test page.

As expected, the server return 401 for the protected links if you are not logged in. However, when I log in, the server now returns 200 for all the protected pages each time i reload. I have testes several times, but I havn't been able to reproduce the bug above. You can create an account for free and try yourself.

[demianrenzulli]

Hi @simensol, thanks for putting this test together.

Here are some observations:

When logged out, I'm seeing some requests returning 401: /dataset/all, /dataset/new, /analysis, /user/profile.

Now, if you take one of these requests and you try to open the URL on the browser, you will also receive a 401 response. e.g. https://easystat.com/user/profile. This suggests that it is not a quicklink / prefetch issue, but that, perhaps, your servers are returning 401, in the absence of some header value (could it be the session?).

When logged in, I'm seeing all these requests being prefetched correctly (return 200).

I think the best solution you can apply in these cases in quicklink side, is to ignore the urls returning 401. In any case, since links like /user/profile, can be clicked directly by users, perhaps you'd want to change your server response for those?

In summary: I don't see any issues with the library itself, this seems to be the intended behavior. Let us know if you have any thoughts.

[simensol]

Thanks for testing, @demianrenzulli.

However, if you see my previous post, you see that the page /analysis was successfully prefetched (server returned 200), while /upload was not (server returned 401), although both pages required the user to be logged in. And as for @matoululu, removing quicklink removed the issue.

However, I'm not able to reproduce the issue any more, using easystat.com/quicklink. So maybe it has been fixed somehow.

[demianrenzulli]

Thanks for your reply @simensol! I couldn't reproduce this either, so I guess the issue might be solved at this point.

In any case, I would suggest keeping an eye on any pages that might be returning 401 (as the I shared before: https://easystat.com/user/profile), just in case this is not related to Quicklink.

Based on your feedback, I'm closing this issue now, but feel free to reopen if you find this issue again.