Problems logging in using Brave on iPad

resolved

#1

I started using Brave recently and when I try to login, I click Login and nothing appears to happen. I do it a few times just the same, I refresh the page, no better, then after a few more clicks of Login and finally it works.

Also, using Brave I have to login every day, where Safari seems to stay logged in, so I experience this login problem every day.

Just tried Safari, had to log out, then login worked first time.


#2

Just had same problem logging in from my laptop using Firefox 64.0 (Quantum). Multiple clicks on the Login button, a refresh, multiple more clicks, then it logged me in.


#3

I’ve have this behaviour of difficulty login in too using Safari on Mojave. It’s not new, and I should have reported it earlier. It seemed to improve once I eventually accepted the cookies, but it has happened again so that may not be related.


#4

Thanks for reporting - I’ve logged an issue (https://github.com/TheRestartProject/restarters.net/issues/106) and we’ll get to the bottom of it.

(If either of you are feeling adventurous, if you could have a look in the browser’s javascript console/debugger to see if any errors are reported there, that would be helpful! In Brave, I believe pressing F12 brings up the developer tools. These are the instructions for Safari.)


#5

There’s no F12 on my iPad keyboard :frowning:

Haven’t been able to get Brave on laptop to reproduce it.

Got FF to reproduce it:

Firefox 64.0 Quantum logging into to https://restarters.net/dashboard

Failed login

Source map error: TypeError: NetworkError when attempting to fetch resource. Resource URL: moz-extension://77791197-ae00-44a4-bef1-7cfc57a92b98/dist/purplebox.js Source Map URL: purplebox.js.map[Learn More]

unreachable code after return statement[Learn More] js:87:1788

unreachable code after return statement[Learn More] js:147:462

unreachable code after return statement[Learn More] js:147:506

unreachable code after return statement[Learn More] js:147:462

unreachable code after return statement[Learn More] js:87:1788

unreachable code after return statement[Learn More] js:147:506

Source map error: TypeError: NetworkError when attempting to fetch resource. Resource URL: moz-extension://77791197-ae00-44a4-bef1-7cfc57a92b98/dist/page_performance.js Source Map URL: page_performance.js.map[Learn More]

Loading failed for the <script> with source “https://www.google-analytics.com/analytics.js”. login:1:1

Loading failed for the <script> with source “https://www.google-analytics.com/analytics.js”. login:1:1

Followed immediately by: Successful login

Source map error: TypeError: NetworkError when attempting to fetch resource. Resource URL: moz-extension://77791197-ae00-44a4-bef1-7cfc57a92b98/dist/purplebox.js Source Map URL: purplebox.js.map[Learn More]

unreachable code after return statement[Learn More] js:87:1788

unreachable code after return statement[Learn More] js:147:462

unreachable code after return statement[Learn More] js:147:506

unreachable code after return statement[Learn More] js:147:462

unreachable code after return statement[Learn More] js:87:1788

unreachable code after return statement[Learn More] js:147:506

Loading failed for the <script> with source “https://www.google-analytics.com/analytics.js”.

dashboard:1:1

Source map error: TypeError: NetworkError when attempting to fetch resource. Resource URL: moz-extension://77791197-ae00-44a4-bef1-7cfc57a92b98/dist/page_performance.js Source Map URL: page_performance.js.map[Learn More]

I have captured HAR files for both failed and successful login I can send you direct if they might be useful.


#6

Thanks @Ian_Barnard!

I can’t see anything there that immediately jumps out as being related to the restarters.net login. (It’s possible that the failed loading of another script might cause an issue further down the line, but I notice that the failed loading also occurred on your successful login attempt.)

If you could send the HAR files to me that would be very helpful, they might contain some extra info that could be of use, thanks a lot :slight_smile:

Another thought is whether you have any javascript blockers enabled. It seems unlikely this would be the issue, if it is only occurring sporadically, but worth checking at least (fresh in my mind from a different issue reported by Andy)


#7

At the moment, the only blocker I use is Ka-Block! and some recipes in the userContent.css (originally based on FloppyMoose).


#8

The only error I can see is:

Content blocker prevented frame displaying https://restarters.net/dashboard from loading a resource from https://www.googletagmanager.com/gtag/js?id=UA-46050944-1

I wonder if it may be indirectly related to this resource loading problem. When I checked the console. I noticed that I was eventually logged in. So it is possible the issue is one of reentry, i.e.,

  1. I try to login
  2. The site is trying to load that resource. Not seeing that and not being logged, I reenter my user id/password and try to login again
  3. Repeat 1 and 2 until the timing is just right and I log in

Don’t know if that’s really what happens but that would match my experience.


#9

I have an AdBlock on my tomato router which is normally enabled - didn’t seem to make any difference to iPad login problems when I disabled it. Firefox on laptop has Ghostery installed but trusting restarters.net didn’t make any difference.


#10

Some more info:

a) If I try to enter my login/password and press return just after the login page is loaded, then the login fails.

b) If I load the page, enter my login/password, then wait for a few seconds before pressing return (or clicking the login button) I am logged in and redirected to the dashboard.

That clearly indicates that something happens in the background, which could well be timing out on the loading of an unnecessary script, that is preventing the logging to work.

I noticed another issue which may or may not be related. I’ll include it here, but @neil if it’s unrelated feel free to separate it:

c) After a successful login I’m redirected to the dashboard. If I then click the ‘Welcome to the Restarters Community’ link in the ‘Discussion forum’ box on the top left of the page, I do end up on the Discourse page as expected. However I appear to not be logged in, and at the I’m offered to ‘Log In’. If I navigate to any other page, rather than clicking ‘Log in’, I’m still in the same situation that I appear logged out. However, if I click ‘Log in’, I’m automatically and instantly logged in, without having to reenter my credentials. So it looks like the state machine for the SSO has a bug where you can end up in a state where you’re not quite logged in (the log in button appears and the page is not personalised), but not quite logged out either (as clicking on the log in button is enough to be logged in without reentering credentials).


#11

On my laptop Brave, I tried stopping my frenzied (well, not exactly, let’s tone that down to ‘repeated’) clicking on Login, took a deep breath, waited five seconds then calmly clicked Login and it worked.

But then while still sat at desk I picked up my iPad and Brave was still logged in, which hasn’t happened before. Then while trying to find this topic on iPad, my laptop showed a dialog ‘you are logged out’, and when I logged back in on laptop the iPad seemed to log out. So something has changed and seems a lot better.

So I don’t know if you’ve changed something consciously/deliberately, or accidentally, or at all, @neil but for me the login seems to be working at the moment.


#12

Thanks both - certainly hints at some kind of timing issue. I experienced the same problem recently on Chrome when hitting enter immediately after entering my details - again, perhaps before a script had completed loading. Hopefully this will help me recreate the issue and we can get it fixed.

Thanks @Panda, we’ve seen the second issue also, I’ve raised it on the Discourse forum but without any response as of yet. I’ll split your comment into a separate issue and go into some more detail there.


#13

Just bumping this topic with an additional report of logging in issues from @ssebti and @Nebojsa_Adzic. They’ve found that sometimes entering their details and clicking the login button seems to refresh the form.


#14

Being patient and letting e.g. four seconds pass on the login screen before clicking Log In seems to work reliably for me.


#15

Had another look and think I’ve resolved this now. Could you try again and see if the problem is fixed?


Turns out this was nothing to do with javascript. We have a honeypot field on any forms that can be submitted before being authenticated, as an alternative to a CAPTCHA test. As part of the honeypot there is also a time value for how long it takes to complete the form, and if the form is submitted in less time than this value, the honeypot doesn’t let you in, assuming that the form has been filled in suspiciously quickly. The trouble is, this value had been set to 5 seconds! This is reasonable for say a registration form, but for a login form it is obviously too short, particularly when using a browser/password manager that autocompletes the form for you.

I’ve changed it to 1 second for the login form. Let me know if this still causes issues, as with autocomplete the form can still easily be filled and submitted quicker than that if you’re really trying. We could arguably remove the honeypot time altogether from the login form, as a spambot spamming the login doesn’t really cause any issues like it would on a registration form, so just the honeypot field by itself would likely be enough.


#16

I haven’t exactly timed myself but that feels a lot better. Now I’ve got to get out of the habit of counting to five-and-a-bit when I log in!


#17

Yes. Getting it to fail is indeed now much harder! Thank you for the fix and the explanation.


#18

Thanks both, I’ll mark as resolved for now, but if it transpires that 1 second is too short, we can easily revisit and probably remove the time check altogether.


#19

@neil I can login happily now, thanks for finding that problem. However on my ipad Safari will stay logged in overnight while with Brave I have to login most every time I come back to the tab - any idea why this happens?


#20

@Ian_Barnard Hmm yes a few people have reported this - thanks, that’s a useful extra data point to have, that you mention Safari stays logged in, but Brave not. And also that it seems to happen every time you visit the site in Brave.

When you log in you should basically be given a persistent cookie that keeps your credentials in your browser so you don’t have to log in again until it expires. It should at a minimum last 7 days. For some reason that cookie must be expiring early.

Do you by chance have anything set in Brave that clears all cookies upon closing the browser?

Another question - I think from what you’ve said previously you tend to navigate to talk.restarters.net by default? This is where you are usually navigating to on both browsers?


More thoughts inside, just me thinking it through, feel free not to read the rest unless it's of interest :)

So as mentioned we have persistent cookies that should avoid the need to log in.

Things are complicated slightly for us in that we end up with 2 cookies for this, one which is used for the software we use for the Talk module (Discourse), and one for the Restarter/Fixometer module (our own custom app). The Fixometer module acts as the authentication mechanism for Discourse, so usernames/passwords are only stored in one place. If you are not logged in to Discourse, Discourse sends a request to authenticate you to the Fixometer. If you’re already authenticated via Discourse’s cookie, you’ll be logged straight in to Discourse. If you’re not, you’re be prompted to log in to the Fixometer, and then will be redirected.

The Discourse cookie is set to 60 days expiry by default. The Fixometer module is set to 7 days. (doesn’t affect the issue at hand, but it doesn’t really make much sense to have them different, so we should probably rationalise that…) As far as I understand they should also both be ‘sliding expiry’, too, which means the expiry time is since your last activity in the module, as opposed to an absolute time since you logged in.

So when you first log in to Restarters.net, if you look in your cookies you should have one called restarters_session, on the domain .restarters.net, with an expiry 7 days from now. Then, if you navigate to talk.restarters.net, you’ll be given a cookie with a domain of talk.restarters.net, called _t, with an expiry 60 days from now.

Logging out in the Fixometer module will invalidate your restarters_session cookie, however it doesn’t touch the _t cookie. Logging out of Talk will invalidate both cookies.

So if someone has logged in to Talk, and is then logged out again prior to 60 days, this would appear to be an issue with Discourse? Because Talk, once it has it’s own cookie, doesn’t even look at the Fixometer auth?

Possible problems, even if the cookie is valid and persisting:

  • if something happens server-side, e.g. a restart or a cache being cleared, then I would suspect the session will expire because the session value will no longer be present on the server. Our own server does not get restarted daily. Don’t know about discoursehosting, but it’s unlikely because then all customers would be experiencing this? This would also not explain Brave having to log in each time.

Other mentions of similar problem: