WebSocket over insecure connection error when using HTTPS

[TheDcoder]

Describe the bug
Tracking doesn't work with an HTTPS end-point server, this message is displayed whenever the app is opened after the first initial login:

Failed to construct 'WebSocket': An insecure WebSocket connection may not be initiated from a page loaded over HTTPS.

To Reproduce
Steps to reproduce the behavior:

1. Set the server URL to an https:// location
2. Login
3. Restart the app
4. See error

Expected behavior
No error

Smartphone (please complete the following information):

• Device: ASUS
• OS: Android 11
• Browser: Firefox (Fennec) Android System WebView
• Version: 100.1.3 96

Additional context
This might be a security issue specific to mobiles with Firefox set as the default browser. Somehow the app or website is trying to connect with HTTP even when the page is loaded via HTTPS.

This issue does not happen when the website is directly used from Firefox.

[tananaev]

Do you have a URL to try? Are you sure you configured your HTTPS proxy correctly?

[TheDcoder]

Do you have a URL to try?

I used the default demo server, but changed http to https 😄

Are you sure you configured your HTTPS proxy correctly?

I am not using a proxy.

[tananaev]

Just tested Firefox 100.0.2 (latest stable release) with demo and no issues.

[TheDcoder]

Did you set it as your default WebView implementation? The issue only happens in the app, not in the browser itself.

[tananaev]

No, haven't tried. Seems like an issue with your setup if it works in the browser.

[TheDcoder]

That's the issue, I can't control the setup inside the Manager app 😄

Something is causing the connection to be made via insecure protocol and it's (rightly) being blocked by Firefox due to security concerns.

[tananaev]

Have you tried the default Chrome-based WebView?

[TheDcoder]

Unfortunately I don't have that on my phone as I use a custom distribution (ROM) of Android.

So far I have not experienced any WebView issues with any of the other apps I use, so I think it's just some simple bug that we need to find and squish!

I'm willing to help with debugging the issue, is there a way to get access to the browser console of the WebView inside the app?

[tananaev]

With the standard Chrome WebView you can access developer tools in the debug mode. Not sure about custom WebView.

[TheDcoder]

I see, sounds tricky...

Am I correct to assume that the manager app is just a shell for the remote website? If yes, then we can debug the website directly and review the code responsible for making the WebSocket.

[tananaev]

I already reviewed the code. Here's the relevant part:

https://github.com/traccar/traccar-web/blob/master/web/app/controller/Root.js#L245

[TheDcoder]

It's hard to go wrong with that code.

Can I deploy a local server with modified code to test it out? Perhaps we can catch this specific exception and modify the logic to try again with wss in that case.

Which parts do I have to install in the backend to do this?

[tananaev]

How would a local server help? All this code is run on the client, not server.

[TheDcoder]

I want a local server so that I can serve my modified JavaScript code and test it with the manager app.

P.S I know web development and JavaScript :)

[tananaev]

We have documentation on how to run it locally.

[TheDcoder]

Okay, thanks. I will take a look and let you know.

[TheDcoder]

@tananaev I set up my own server and the issue remains, which makes sense I guess.

I modifying the Root.js file by adding this new line just after the code to detect protocol:

throw new Error(window.location.protocol);

I was hoping the error would show up with the required info in a similar fashion but it doesn't, I get the same old error about WebSocket.

I see that the server is sending "packed" JavaScript, I am not familiar with this but I'm guess this means by changes weren't propagated, is this true? If yes, how do I refresh the cache so that my modified JS gets sent?

[tananaev]

You can try opening debug.html. It uses original non-minified JS files.

[TheDcoder]

Can I open it in the app? If not then I'm afraid we'll have to find another way.

The whole point of what I'm trying to do is debug the issue without using the developer console since we don't have access to that in the app, so it's no good if we can't access debug.html from the app.

[tananaev]

You can set this in the config:

<entry key='web.debug'>true</entry>

And it will default to the debug version.

[TheDcoder]

Awesome, I just did that but something very strange happened. I opened up my instance in a fresh desktop session and it did load all of the files individually, but it presented me with the "old" login interface! Then I went to the modern interface manually (there was no option shown in old interface) by appending /modern to the path, but it loads the packed files and I don't see my custom error message 😢

[tananaev]

Does the WebSocket work in the old interface?

[TheDcoder]

Can it be accessed from the app?

I did not test in desktop because the issue never happens there (even in Firefox).

[tananaev]

Not sure I understand the question.

[TheDcoder]

Can I access the old interface in the Traccar Manager app? I can't find an option to do that.

[tananaev]

Yes, you can. In debug mode it should show by default.

[TheDcoder]

@tananaev I did some tests and the old interface always works and it displays https: every time. The modern interface still has the issue however 😞

[tananaev]

But what about websocket?

[TheDcoder]

WebSocket works fine in old interface, that's what I was trying to say. Now we have to figure out why it doesn't work in the modern interface.

[tananaev]

Can you please provide a screenshot.

[TheDcoder]

Sure

[tananaev]

Obviously I meant a screenshot proving that the websocket connection worked on the old app. A screenshot from browser network tool or something like that.

[TheDcoder]

Sorry, my bad. I cannot access the browser network tool from the traccar manager app, so I cannot give you a screenshot.

But the old interface does work as I can see the status of my devices and their locations on the map, this doesn't happen with the modern interface.

[tananaev]

Legacy app has a fallback to regular API if WebSocket fails, so the fact that it works doesn't really prove that you don't have some WebSocket configuration issue.

[TheDcoder]

I see, then I guess it means the WebSocket issue could still be present, I'll perform more investigation in the weekend.

WebSocket configuration issue.

By the way, I don't think it's a server issue because of a few reasons:

1. The same issue happens with the official demo server
2. WebSocket always works during the initial login, the issue only happens after you close and reopen the app
3. It always works in the browser, both in mobile and desktop.

[TheDcoder]

@tananaev I just found something very important:

Turns out it is not Firefox, it's the default Android web-view and I cannot change it to Firefox for some reason. So I am assuming it's going to be easier to debug this, can you give me instructions on how to do this?

[tananaev]

I'm pretty sure you need a debug build to connect to the WebView.

[TheDcoder]

@tananaev I see, can you give me a test build with the debugging feature enabled?

[tananaev]

You can compile it using Android Studio.

[TheDcoder]

I currently don't have it and it's a huge download, plus I'm not familiar with Android development at all. So I'd be grateful if you can provide a test build APK with the debugging feature 😄

[tananaev]

You can also compile it using the following command:

./gradlew :app:assembleRegularDebug

It will give you an APK file as an output.

[TheDcoder]

How would I access the developer tools in this debug build?

[tananaev]

From a desktop Chrome browser.