First load of Meteor App on Root URL doesn't log users in

help
1

I am perplexed. When you load my website from it’s root url (For example: www.example.com) it will act as if you’re logged out. But

  • If you click on any link (To a router path) from this page (For example, a link that takes you to www.example.com/test) then the app will promptly realize you have a session and log you in (while also taking you to the route you clicked on)
  • Loading mostly any other page of my site as your first load will log you in normally (For example if you open up a new tab and type in your brower “example.com/test” then you will land on my site and (assuming you’ve logged in before) the app will promptly know who you are and display your name.

This is a problem because the root url contains the “hub” page which I have heavily customized to my users profile. Some things I’ve tried
~ Disabling fast render (Didn’t change anything)
~ Changing the route path (Nope)
~ “Clear cache and hard refresh”

So it must have something to do with my template right? Except I don’t see anything unusual. The most unusual things are
~ I have a higher number of functions scoped outside of template “events/helpers/oncreated” wrappers.
~ I use “require(dragula.js)”

Also I should mention this all works COMPLETELY fine on any local versions of my website (localhost:3000). It only shows up on the hosted version of page (example.com), which makes debugging annoying.

Edit: Wait, it seems moving the template to a different url DOES work. The reason it didn’t work before was because I was then redirecting the root url to the new url, which DOESN’T work. Uhuh…
So I would still like to solve this.
Additional information: I’m using Iron Router.

Edit2: This may not be as clean cut as it appears. I’ve found that while loading my hub page (now located at “example.com/portal”) it works. But if I load the site from “example.com” (Which is now iron routers default 404 page) and then change the url in the address bar to “example.com/portal” it doesn’t work.

2

Welcome to the forums @Friction-less!

My first thought is that the user data isn’t ready when the template first renders. Meteor sends user info using a publication, so that data will usually load after the page first renders.

How are you checking that the user is logged in on that page?

Are you checking if Meteor.loggingIn() is true?

3

Hello. When typing Meteor.loggingIn() into the console log on the glitched instances of the page I get false.

How I check if the user is logged in is
“if Meteor.userId()” or sometimes “if Meteor.user()”.

4

Not on the console, but at the moment the template chooses to render the hub or not

Can you post some code so I can get a sense for what’s happening?

5

It’ll take me a minute to deploy to test the “loggingIn” thing. But an example of my code

<ul>
                    <li><a class="index" href="{{urlFor route="index"}}">Home&nbsp;&nbsp;</a></li>
                    {{#if currentUser}}
                    <li><a class="members" href="{{urlFor route="members"}}">Members&nbsp;&nbsp;</a></li>
                    <li><a class="profile" href="{{urlFor route="userSettings"}}">Profile&nbsp;&nbsp;</a></li>
                    <li><a class="logout">Log out&nbsp;&nbsp;</a></li>
                    {{else}}
                    <li><a class="login" href="{{urlFor route="login"}}">Log in&nbsp;&nbsp;</a></li>
                    <li><a class="register" href="{{urlFor route="register"}}">Register</a></li>
                    {{/if}}

                </ul>

currentUser is a default blaze helper.

I use user-data more in-depth in later parts of the code but it’s the same principal. “If user exists, go off their settings otherwise use default settings”.

7

Maybe try something like:

<ul>
    <li><a class="index" href="{{urlFor route="index"}}">Home&nbsp;&nbsp;</a></li>
    {{#if loggingIn }}
        <li>Logging in...&nbsp;&nbsp;</li>
    {{else}}
        {{#if currentUser}}
            <li><a class="members" href="{{urlFor route="members"}}">Members&nbsp;&nbsp;</a></li>
            <li><a class="profile" href="{{urlFor route="userSettings"}}">Profile&nbsp;&nbsp;</a></li>
            <li><a class="logout">Log out&nbsp;&nbsp;</a></li>
        {{else}}
            <li><a class="login" href="{{urlFor route="login"}}">Log in&nbsp;&nbsp;</a></li>
            <li><a class="register" href="{{urlFor route="register"}}">Register</a></li>
        {{/if}}
    {{/if}}
</ul>

Although the currentUser helper should re-run on it’s own once the user is logged in, so this is a bit unusual.

on my app I use flow-router-extra and check if someone’s not logged in and not logging in before redirecting them:

const loggedInRoutes = FlowRouter.group({
    name: 'loggedIn',
    triggersEnter: [
        (context, redirect) => {
            logger.debug('Entering logged in area');
            if (!Meteor.userId() && !Meteor.loggingIn()) {
                logger.debug('Router: firing not-logged-in action');
                const current = FlowRouter.current();
                logger.silly('Router: flowrouter.current()', current);

                if (current.route.name !== 'login') {
                    RouterState.set('redirectAfterLogin', current.path);
                    redirect('login');
                }
            }
        },
    ],
});
8

Well the code above (In my previous post) works perfectly fine when loaded off other url’s (As noted in the op). It’s part of the “header” code. (layoutTemplate in iron router)

It’s just when the user initially loads the site off the root url ("/" path in ironrouter. “example.com” in deployment) that this happens. I’ll keep testing.

9

Alright, in a part of the code where I check “Meteor.user()” to determine what to render, I console logged “Meteor.loggingIn()” and got false.

The next thing I’m going to test is to put a completely different template on the root url and see if it still has the same problem.

10

Yeah putting another template on the root url (A template that I’ve had no problems with previously, either as an initial load spot, or a spot I’ve navigated to later on after loading the app) causes the same thing to happen on THAT template.

So in other words I basically duped the route data “example.com/fungames” and put a copy of it on “example.com”. (basically copy/paste the route entry but change the route name to something else and route path from “/fungames” to “/”). When I load “example.com” from a new tab I have the “not logging the user in” issue. When I load the SAME CONTENT from a new tab “example.com/fungames”, it works fine.

So it’s not an issue with the template, it’s something to do with the root url.

I don’t know what could be causing this. The next thing I’ll likely do is just remove packages at random to see if any of them are causing this. But I probably won’t do that tonight and will instead leave this forum open to see if anyone else has an idea.

(btw thanks for your help so far coagmano)

1 Like
11

Oh and if anyone has any ideas here’s a list of packages in use

Meteor packages

meteor-base@1.4.0 # Packages every Meteor app needs to have
mobile-experience@1.0.5 # Packages for a great mobile UX
mongo@1.6.2 # The database Meteor supports right now
blaze-html-templates@1.0.4 # Compile .html files into Meteor Blaze views
reactive-var@1.0.11 # Reactive variable for tracker
jquery # Helpful client-side library
tracker@1.2.0 # Meteor’s client-side reactive programming library

standard-minifier-css@1.5.3 # CSS minifier run for production mode
standard-minifier-js@2.4.1 # JS minifier run for production mode
es5-shim@4.8.0 # ECMAScript 5 compatibility for older browsers.
ecmascript@0.12.4 # Enable ECMAScript2015+ syntax in app code
shell-server@0.4.0 # Server-side component of the meteor shell command

iron:router
frozeman:template-var
dynamic-import@0.5.1
underscore@1.0.10
accounts-password
check
aldeed:collection2@3.0.0
meteorhacks:subs-manager
session
matb33:collection-hooks
jparker:crypto-aes
peerlibrary:reactive-publish
ostrio:files
staringatlights:fast-render -> (As stated above I disabled fast render (Didn’t completely remove the package yet though, I should try that.)
ostrio:iron-router-meta
mizzao:user-status
gadicohen:sitemaps
allandequeiroz:rss2.0
email
ddp-rate-limiter

Npm pacakges

“@babel/runtime”: “^7.4.5”,
“bcrypt”: “3.0.0”,
“chess.js”: “^0.10.2”,
“dragula”: “^3.7.2”,
“fibers”: “^4.0.1”,
“frappe-charts”: “^1.2.3”,
“fuse.js”: “^3.4.5”,
“hammerjs”: “^2.0.8”,
“jquery”: “^3.4.1”,
“markdown-it”: “^8.4.2”,
“markdown-it-emoji”: “^1.4.0”,
“meteor-node-stubs”: “~0.2.0”,
“mmmagic”: “^0.5.3”,
“simpl-schema”: “^1.5.5”,
“simple-schema”: “^1.1.0”,
“simpleschema2”: “^1.1.18”

12

I did not read through your thread closely… But is it possible you are encountering #10157?

13

Maybe, it doesn’t immediately strike me as the same issue but I’ll look into it.

Additionally last night I realized something.

It’s not mind-blowing but when I was investigating fast-render I noticed that fast-render scans the localStorage for login data and if it finds it, transforms it into a cookie.

On the glitched instances of my page loading, fastrender was NOT making a cookie (It did otherwise). Meaning it wasn’t finding localStorage login data on the page (Same as meteor when it fails to log me in). I wonder if for some reason my browser is loading a version of the page that doesn’t have access to localStorage (Like maybe www.example.com has different access rights from https://example.com and my browser is loading one or the other for some reason. Though the fact that this works on other URL’s is still perplexing.)

I may just fix this by having a neutral landing page (Note, automatic iron router redirection still causes issues, something about that initial load. Template automatic redirection MIGHT work, but then might as well have a “Welcome” page if we go that route.) on my root url and move the hub to /hub and train users to access it there. It’s not ideal but not the worst solution.

14

It sounds like where ever you are checking Meteor.userId() is not reactive on that first page (and is therefore not reacting to the change after initialization). Are you sure you are checking that inside a computation?

A side note: I’ve found that Meteor.userId() returns 3 different values - very early (before the system has completed initialization) you’ll get undefined. After that you’ll either get null if the user is not logged in, or a user id string if the user is logged in.

15

Yeah in the glitched instance of the page load meteor.userId() is returning null, but I don’t think what you’re describing is the problem. I check the Meteor.userId() after it loads (using console log) and it’s still null so there’s no change to react to regardless.

Also like I said, the same template works completely fine if the initial load is from a different url than the root.

16

That is weird. In that case, maybe @brucejo has identified the right problem. The only reason I can see that happening on root is if you are loading extra stuff there compared with other routes, and somehow causing a delay there that doesn’t exist elsewhere. The bug should be fixed, but maybe you can work around it by using dynamic-imports on the larger modules?

Actually, I wonder if something like the accounts-base package getting split to a secondary load (using dynamic-imports or for some other reason) could be causing this - if you put 'import 'meteor/accounts-base' at the top of your main entry module, does that fix it?

17

Putting

import 'meteor/accounts-base';

in main.js doesn’t change anything.