Welcome Guest Search | Active Topics | Sign In | Register

CustomUserAgent not accepted [20.3.34] Options
unicore
Posted: Friday, December 4, 2020 2:29:53 PM
Rank: Newbie
Groups: Member

Joined: 10/9/2016
Posts: 3
Hi,
I have a problem, assigning CustomUserAgent on tunneling https (EO.Webbrowser v20.3.34).
When creating a tunnel, the same UserAgent is always transmitted.

Code: Visual Basic.NET
m_WebView.CustomUserAgent = "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.114 YaBrowser/20.11.1.97 Yowser/2.5 Safari/537.36"


CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.113 Safari/537.36

In the http headers POST/GET, UserAgent is passed correctly. In the previous version EO.2019, this worked correctly.
Thank you in advance!
eo_support
Posted: Monday, December 7, 2020 1:30:19 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,217
Hi,

I am not exactly sure what you meant by tunneling https. Do you mean to access an HTTPs website? We tested it here and it appears to work fine.

Our step is to modify TabbedBrowser sample application by adding the following line:

Code: C#
webView.CustomUserAgent = "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.114 YaBrowser/20.11.1.97 Yowser/2.5 Safari/537.36";


Inside WebView.cs at line 70. We then run the sample application and access https://www.google.com and we can see the above custom user agent was used.

If you meant something different, please let us know and we will check again.

Thanks!
unicore
Posted: Tuesday, December 8, 2020 5:55:19 AM
Rank: Newbie
Groups: Member

Joined: 10/9/2016
Posts: 3
Sorry, my english is very bad.
The problem is deeper.
In normal HTTP packets, User-Agent is transmitted correctly. But, when connecting via the httpS tunnel (SSL), a completely different User-Agent is transmitted in the FIRST packet, which is specified in the CustomUserAgent.
Some site defenders react poorly to this.
In the EO.Webbrowser 2019 version, User-Agent was transmitted correctly everywhere.

eo_support
Posted: Tuesday, December 8, 2020 9:39:55 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,217
I see. Can you provide information about your test server and related code/credential to us through private message? Once we have that we will debug into it here and see what we can find.
unicore
Posted: Thursday, December 10, 2020 6:02:20 AM
Rank: Newbie
Groups: Member

Joined: 10/9/2016
Posts: 3
Hi,
To identify the error, can use any project EO.Webbrowser v2020.3.34 (Win7x64/Win2008r2/WinSrv2016/WinSrv2019), for example "\EO.Total 2020\Samples\CS\WebBrowser\TabbedBrowser\"
Paste in function 'WebPage' two lines of code (Proxy and CustomUserAgent)

Code: C#
public WebPage(EO.WebBrowser.WebView webView, EO.Wpf.TabControl tabControl)
        {
            ///////.....sample code...../////

            /////////////////////////////////////////////////////////
            //a proxy server is required to test the project for Fiddler Web Debbuger
            m_WebView.Engine.Options.Proxy = new EO.Base.ProxyInfo(EO.Base.ProxyType.HTTP, "127.0.0.1", 8888);
            m_WebView.CustomUserAgent = "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.114 YaBrowser/20.11.1.97 Yowser/2.5 Safari/537.36";
            /////////////////////////////////////////////////////////


Run Fiddler Web Debbuger. The "Hide CONNECTs" option must be disabled in Fiddler.



Run sample project TabbedBrowser. Next, go to any site that supports the httpS protocol. For example, https://www.google.com/



As a result, in all HTTPS tunnel creation packages, the built-in User-Agent name is transmitted, and not the one that we specified in the CustomUserAgent.










Regards
eo_support
Posted: Thursday, December 10, 2020 11:00:59 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,217
Hi,

Thanks for the additional information. We have found the root of the problem. This only occurs when you use a proxy server, which is why it shows up in Fiddler because Fiddler acts as a proxy server. In another word, only the proxy server will receive the old user agent. The actual web server should always receives the new user agent.

Because the connection to the proxy server is not necessarily associated to a specific request, our existing model of setting user agent per WebView will not work for this situation. As a result, we will address this issue in our next build as follow:

1. Add CustomUserAgent property to EO.WebEngine.EngineOptions class. This will be the recommended way to set user agent that should cover all connections, including the proxy server connections;
2. WebView.CustomUserAgent will be marked as obsolete and gradually phased out;

We will reply again when the new build with this change is available.

Thanks!
eo_support
Posted: Friday, December 18, 2020 4:08:37 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,217
Hi,

This is just to let you know that we have posted a new build that should resolve this issue. You can download the new build from our download page. Please take a look and let us know how it goes.

Thanks!
rainstuff
Posted: Saturday, December 19, 2020 10:45:18 AM
Rank: Advanced Member
Groups: Member

Joined: 9/20/2016
Posts: 73
I have a question. How to change User Agent on the fly?
Currently I can change User Agent using WebView.CustomUserAgent, but this method will be removed in the future.
I tried to change it via EO.WebEngine.EngineOptions (WebView.Engine.Options.CustomUserAgent) but it hasn't changed.
eo_support
Posted: Saturday, December 19, 2020 11:33:52 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,217
Hi,

Generally you should not try to change user agent on the fly. There are three places user agent are used:

1. When a request is sent. This one can be easily changed on the fly by handling BeforeRequestLoad event and then override user agent header entry there. This value is sent to the web server;
2. When a proxy connection is made. The user agent value used by this is a preset global value but can be overriden by WebView.Engine.Options.CustomUserAgent. This value is sent to the proxy server;
3. When the page tries to Navigator.userAgent to get user agent. This value previously comes from WebView.UserAgent, now it comes from step 2. This value is reported to your JavaScript code but not explicitly sent to anywhere;

You can only change the one used in the step 1 on the fly now.

Thanks!


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.