403 Forbidden connecting to Raspberry Pi - TeamViewer doesn't prompt me for the web server user name

I think you will now only be able to reproduce it, if you want to reproduce it, is if you use the previous redirection method of the library and then switch to the current one.

Anyways, I have taken into account the problem with the caching in TeamViewer. If you happen to face any other problem in future then just open a new thread.

All comments

I think you will now only be able to reproduce it, if you want to reproduce it, is if you use the previous redirection method of the library and then switch to the current one.

Anyways, I have taken into account the problem with the caching in TeamViewer. If you happen to face any other problem in future then just open a new thread.

Could you please also tell the TeamViewer version? Also please update TeamViewer version and try again.

Running

sudo teamviewer-iot-agent info

shows that the version is 1.1.102, which is the latest version AFAIK. I did uninstall and reinstall that version today, without success.

Sorry. I meant TeamViewer windows version?

Oops, I should have picked up on that - it's 13.2.5287. I'll download the latest version and give that a try. Since this version used to work, I assumed the problem would be elsewhere.

I see that I already had the latest version. I uninstalled an reinstalled TeamViewer on Windows anyway, but that doesn't make any change.

I went and removed the redirect from HTTP on port 80 to HTTPS on port 443. That allows me to view the web server via TeamViewer, and I get prompted for my password, but this isn't a solution because it isn't secure.

No, thats not the solution. It should also work with the redirection as it was working before. It seems like a bug. Could you please send the log files of TeamViewer Windows and teamviewer-iot-agent to https://www.teamviewer.com/en/support/.

Thanks @arpitjindal. It looks like part of the problem comes from the way in which the web server library I use was doing the redirect. There's at least two ways to get it to redirect users from HTTP to HTTPS (both are supposed to produce the same result), but the one I was using no longer works. I didn't pick up on this because Google Chrome doesn't generate any errors. However, using an incognito window results in the same problem I reported here.

So, after fixing that problem, now TeamViewer just shows the text "Not Modified". At least it does ask me for my user name and password, so it's progress. I'll report this remaining issue at the link you provided.

Is there a way to force TeamViewer IoT to use HTTPS? I know how to set the port to 443, but then the URL that it uses still starts with http://..., instead of https://.

Good to know there is some progress but I didn't understand the statement "TeamViewer just shows the text "Not Modified" ". Do you mean that in the window only "Not Modified" text is being displayed? I would suggest to first test your web server with IE. Our browser is based on IE engine.

At the moment user can not change http and https protocol prefix but we have already thought about it.

I tried forcing TeamViewer IoT to not cache anything from my Pi's web server by making my web server append the header "Cache-Control: no-cache, no-store, must-revalidate" every time that it serves files. This got rid of the "304 Not Modified" response that TeamViewer was showing. It appears that TeamViewer IoT's browser doesn't correctly handle caching, or perhaps a TeamViewer server between the Pi and my computer isn't correctly caching responses.

Hi @arpitjindal, that's exactly what it would display, "Not Modified". I have actually tested my web server using Google Chrome, and IE. I think that the reason for not encountering the authentication failure before may be related to Chrome caching everything, so there I definitely needed to spend more time testing in incognito windows. However, the "Not Modified" message being displayed doesn't happen with either browser whether in private/incognito browsing mode or not, that only happened with TeamViewer IoT.

After adding the no-cache, no-store and must-revalidate options, TeamViewer IoT was able to correctly show the web page. Now, however, removing those options from the web server response doesn't bring back the problem. I guess that now that TeamViewer was able to download the web page, it could subsequently use it's cached copy. I have verified in IE and Chrome network traffic windows that those cache-control options no longer get sent in web server replies.

Since internally you're using IE, it would be nice if IE's debug tools could be exposed so that I could monitor network traffic.

Good to know its working again. Thanks for pointing out the caching problem. I have to check again why there is caching problem in TeamViewer because we do clear the cache in TeamViewer browser.

As you have removed the caching options now, it would be good to check to clear the cache in IE and try again in TeamViewer.

Microsoft does not provide developer tool options in embedded IE browser.