using ip addresses in http URI at login does not work (any more)
nlmave opened this issue · 5 comments
Prerequisites
- I have written a descriptive issue title
- I have verified that I am running the latest version of the COMET-WEB
- I have searched open and closed issues to ensure it has not already been reported
Description
On login, using the ip address of the server fails to resolve, even though using the server is up. Login referencing to the FQDN does work.
Interestingly, it did work with version 0.33; I've got one machine for which I can only refer to by ip-address and since upgrading to WebApp version 1.3.0 I cannot connect to that server any more (UI shows "The server could not be reached") using the Web app. If I open the same URL in a normal web browser, I immediately get the COMET WSP splash page, so the machine is certainly up and running.
the same seems to be happeingin in IME version 10.x
Steps to Reproduce
In stead of http://f.q.d.n use http://1.1.1.1 (whereby 1.1.1.1 is the (valid) ip address of the FQDN
System Configuration
- COMET version:
- COMET-WEB: 1.3.0
- COMET-IME: 10.0.0.6
- Web Services:
- COMET Web Services version: 7.1.1
Actually I got the dns fixed and when I try it still doesn't work.... I am trying to connect over http to this server and that fails. Connecting to another server over https works... does the login process assume only https?
@nlmave we'll investigate, it should work for both http and https using a dns name and an ip address
Some .net webassembly security setting in play here not allowing access over unsecure channels? I was using Chrome browser btw, will crosscheck with Edge.
Did some more testing. If you deploy COMET web with a reverse proxy over SSL, then that automatically implies that you can only connect to https served COMET web services connections. The detailed error is shown on the console in the browser developer tools. Tested both with Chrome and Edge. This seems to be a standard (and wise :-)) dotnet security policy. Note that if you do not deploy over SSL (meaning that COMET web is delivered over http), then you can connect to COMET web services over both HTTP and HTTPS.
Not sure now if this is "wanted" behavior, but at least the feedback to the user should be improved.
Error message below (redacted - removed the machine name FQDNs)
dotnet.7.0.9.tk6wuja4xx.js:5 Mixed Content: The page at 'https://<comet-web-machine>/' was loaded over HTTPS, but requested an insecure resource 'http://<comet-web-services-machine>/SiteDirectory?extent=deep&includeReferenceData=false'. This request has been blocked; the content must be served over HTTPS.
We should be able to handle this error, however this issue seems to be deeper.
After investigating this issue, I've found a bug that needs to be solved when the httpclient from Blazor is injected in CdpServicesDal. The current implementation of CdpServicesDal updates the BaseAddress everytime Comet-Web makes a login request, resulting in the error below when trying to login more than once:
"This instance has already started one or more requests. Properties can only be modified before sending the first request."
For further information, see STARIONGROUP/COMET-WEB-Community-Edition#422 and This