When webservice client is executed on local domain it is executed with
"localhost" URL, ie.
In liberty case the user will be redirected to the AM for authentication to the
URL like this one
(please notice that AM installed on "hostname/FQDN" which isn't a "localhost")
The successfull authentication at AM:
- sets the cookie that isn't valid for "localhost"
- redirects back to the "localhost" based url, ie.
Thus client isn't considered authenticated and gets redirected back to the AM
where it presents cookie and thus considered successfully authenticated and
redirected back to the WS client URL which is "localhost" based ....
When the Run project is invoked from IDE, the defaukt URL the IDE generates is
with localhost. The workaround for this issue is to access the stockclient from
the browser with the proper hostname and not localhost.
With AM build 5, the installer is installing and configuring AM with localhost
by default for all systems. This fixes this bug also.
Vidhya, I don't think this bug is fixed. The installer changes only made it
less likely to happen. As soon as someone decide to change the hostname to
something that is not localhost, he/she will hit this bug. A workaround needs
to be document for this.
There is already a documentation on this. This needs to be put in
Troubleshooting section or FAQ for FCS.
Vidhya, another issue I just thought about. Now that everything is localhost by
default. No one can test remote instances anymore unless they reconfigures the
am server to use the hostname.
In my opinion, we really need to rethink this hostname issue instead of blindly
setting it to localhost. For example, the installer can ask the user to make a
choice and explain the consequences of their choice.
For M20 build the installer installs AM byd efault as localhost. This issue
should be resolved with this milestone build.
localhost installer change should take care of this
Verified in build22.