You shouldn'thave a problem with an environment that doesn't depend on the loopbackdevice.It's worth noting that a different version of this problem appears in an environment which has a pool of NATing firewalls. I experienced this issue firsthand whilst on Stanford's guest network last week, and we have user reports of problems from other sites. Basically what happens is that one NAT in the pool decides to handle your connection to the central weblogin server, and then a different machine handles the connection to the web application. This trips over the IP check, and breaks your access. Unless you have a VPN handy, it's rather dull.
I'd like to say that this also breaks further with IPv6 (particularly when clients might have several legit IPv6 addresses concurrently, or dual-stacked clients that might present their v6 address to cosign and a v4 address to the filter), service provider transparent web proxies (e.g. AOL), employer proxies (where, for example, some are proxying even SSL connections by means of locally created certificate trust relationships), Verizon's DSL lines that change client IPs every 15 minutes, and probably dozens of other situations. My recommendation to everyone would be to disable this IP address check unless you have a specific reason to think that (a) you really need it and (b) it will work in your specific environment.
-- Jorj
PGP.sig
Description: This is a digitally signed message part
------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects
_______________________________________________ Cosign-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cosign-discuss
