david63 wrote: ↑
Thu Oct 17, 2019 1:47 pm
Could the problem be connected to using a dynamic DNS service?
Maybe elaborate on the kind of issue you think this might create; but there isn't an obvious one already known to me, anyway.
The "cookie decision" is made by the web browser itself; i.e. "I have this cookie saved for the root path of softprocorp.com... so should I be sending this cookie for the current page request or not?"
To make that decision, he's looking at the domain name and path he's being requested to access, and whether the connection is over HTTPS or not. So regardless of what calisthenics might be going on within the DNS service, the web browser is still making its decision based on what URL he's being requested to send this HTTP GET request to.
Something I don't know definitively is that if the DNS name was actually a CNAME for something else, which domain name would the web browser be basing its decision upon. It seems like from a management and design perspective they would have to still use the DNS name being resolved, and not the CNAME it resolved to; but I don't know nor have ever researched that. Regardless, devforum.softprocorp.com is just a direct A record to an IP address, with no CNAME involved.
Still interested to see what the actual requests, responses, and cookies are in the sequence that ends up hitting 401 for OP after the successful ACP login. As will hopefully be revealed in the .HAR file they generate from the Chrome F12 Network tab, if possible. A Wireshark LAN trace with the TLS decrypted would be clear on this point too, but seemed like the more difficult ask to make.