Login page not showing when self hosting locally without internet

Hi CuriousPasserby, please open the console, and tell us if there is any error in console (JS or network). Thanks!

@developmentforpeople

ReferenceError: io is not defined[Learn More] frappe-web.min.js:7753:5
init http://XXX.XXX.X.XXX:XXXX/assets/js/frappe-web.min.js:7753:5
http://XXX.XXX.X.XXX:XXXX/assets/js/frappe-web.min.js:7728:3
trigger_ready/< http://XXX.XXX.X.XXX:XXXX/assets/js/frappe-web.min.js:7560:5
forEach self-hosted:251:13
trigger_ready http://XXX.XXX.X.XXX:XXXX/assets/js/frappe-web.min.js:7559:4
http://XXX.XXX.X.XXX:XXXX/assets/js/frappe-web.min.js:7702:3
dispatch http://XXX.XXX.X.XXX:XXXX/assets/frappe/js/lib/jquery/jquery.min.js:3:7485
add/r.handle http://XXX.XXX.X.XXX:XXXX/assets/frappe/js/lib/jquery/jquery.min.js:3:5603
trigger http://XXX.XXX.X.XXX:XXXX/assets/frappe/js/lib/jquery/jquery.min.js:4:4816
trigger/< http://XXX.XXX.X.XXX:XXXX/assets/frappe/js/lib/jquery/jquery.min.js:4:5320
each http://XXX.XXX.X.XXX:XXXX/assets/frappe/js/lib/jquery/jquery.min.js:2:2859
each http://XXX.XXX.X.XXX:XXXX/assets/frappe/js/lib/jquery/jquery.min.js:2:843
trigger http://XXX.XXX.X.XXX:XXXX/assets/frappe/js/lib/jquery/jquery.min.js:4:5299
http://XXX.XXX.X.XXX:XXXX/assets/js/frappe-web.min.js:7685:3
i http://XXX.XXX.X.XXX:XXXX/assets/frappe/js/lib/jquery/jquery.min.js:2:27146
fireWith http://XXX.XXX.X.XXX:XXXX/assets/frappe/js/lib/jquery/jquery.min.js:2:27914
ready http://XXX.XXX.X.XXX:XXXX/assets/frappe/js/lib/jquery/jquery.min.js:2:29705
J http://XXX.XXX.X.XXX:XXXX/assets/frappe/js/lib/jquery/jquery.min.js:2:29890
Password fields present on an insecure (http://) page. This is a security risk that allows user login credentials to be stolen.[Learn More] login
Invalid chrome URI: /

anyone can help me?

Another user and myself had this very conversation in PM messages late last week. He seems to have tracked it down to this:

As far as I can tell, ERPNext is making a call to this JavaScript file on cloudflare. And the page doesn’t run completely without it.
https://cdnjs.cloudflare.com/ajax/libs/socket.io/2.0.4/socket.io.slim.js

His quote here is about getting the login page to display. His observation indicates that ERPNext login screen now requires a internet connection for it to find this one file in order to complete the loading of the page.

Evidently this has changed recently and nobody is either aware of it or working on it. Maybe this is enough of a clue for you to complete the investigation and pursue a solution. I myself just do not have time to work on it since I never use ‘local only’ installations.

Hope this helps…

BKM

after updating to 11.1.15 I still couldnt login.

does the developers really come here?

anyone know how i can change the files so that it wont check online for a page so that i can access the login page

1 Like

Try localhost access from Firefox?

Chrome now requires and only allows https access from a public facing website?

It’s required a internet connection, because as told by @bkm, there is a JS loaded from the internet:

<script src="https://cdnjs.cloudflare.com/ajax/libs/socket.io/2.0.4/socket.io.slim.js"></script>

It’s normal without an internet connection you get an almost blank page…

1 Like

@clarkej
I am already using firefox for that. not sure why it popped out a chrome error

@fromthestone
I already understood what bkm was saying. I was just asking why they needed a script to load something from the internet. This is more like asking what their intention for doing sucha thing

When in doubt clear the server and web browser caches?

bench clear-cache
bench clear-website-cache

Maybe run also ‘bench build’ #Minify + concatenate JS and CSS files, build…

ok Chrome just complains when a site is http accessible! A milestone for Chrome security: marking HTTP as “not secure”

While there may be a way to get past the chrome user experience with non secured public websites, it does not act in the same manner on all platforms. For instance, on Andriod devices Chrome does not give you a path to a site that is http only.

Just an observation from my installed tablet users. Notably I have also turned off chrome updates to the tablets when the most recent one (two weeks ago) broke the HP print service that I depend on for reports. So, this may have been fixed in that same update and I just have not seen it. chromium for Debian desktops also has this issue.

BKM

socket.io.slim.js

that’s one of the core stuff frappe relies on, no wonder the login page won’t load!

what is a wonder is, why won’t frappe cache it or store the file locally and serve it from there…

1 Like

what is a wonder is, why won’t frappe cache it or store the file locally and serve it from there…

^ TL;DR - This is what should be happening.

This is one of the pitfalls of modern web development. Third party dependencies are awesome. They save us a ton of time. We can quickly handle authentication, database access, error handling, logging, encryption, and much more. Without having to reinvent the wheel and write our own implementations.

But…what happens when these libraries change? Break? Disappear?

External libraries and dependencies need to be downloaded and cached locally. And when the online versions don’t work, we can fallback on the local versions.

I’ve added this as an Issue on GitHub: Bug: Need to cache socket.io.slim.js · Issue #7140 · frappe/frappe · GitHub

1 Like

Yeah, seems like an oversight.

@netchampfaris can you pls fix this?

there was already a similar issue opened in the erpnext github as opposed to frappe github page but they just scoffed it off and said its working as intended then finally closed the issue (please see below link). They didnt even seem to respond back after they closed the issue after the user asked the reason why twice

https://github.com/frappe/erpnext/issues/16962

hopefully they will respond to yours

Fixed:

https://github.com/frappe/frappe/pull/7151

1 Like

@netchampfaris

thanks. If I can ask what was the reason behind why they designed it that way?

@CuriousPasserby As rmehta pointed out, it seems like an oversight. It shouldn’t have been that way.

Thanks @netchampfaris and @rmehta! We’re very glad to know this is fixed. :hugs: