Open an issue -- I'll use it to remember to add this to the developer
documentation (e.g., CONFIGURE.txt?). It isn't a production issue, as if
you run the installer, it will choose either REQUIRES_SECURE_CHANNEL or
REQUIRES_INSECURE_CHANNEL for the secureChannelType. This is more of a risk
with the development environment and rolling your own config.
I was fighting issues like this as I was setting up the configuration, and
that's one of the reasons I locked everything down with the explicit
hostname, port and channel designation.
The cookies are tied to ( http/https + hostname + port ), so any change to
any of these makes the operation a cross-site operation, requiring separate
logins, etc., as you experienced. This is even true if you try to connect
to localhost, if you authenticate as localhost, you cannot then access
anything via the full servername URL without reauthenticating. Very
problematic.
Mitch
On Fri, Jul 20, 2012 at 1:25 AM, Christopher Robert < chrislrobert@gmail.com> wrote:
Hi Mitch,
Okay, rebuilding and redeploying didn't help, but I've cracked the code.
Here's the problem: because I had logged into the site with https I had
only authenticated via https, but the JSON request was being done through
http. When I executed the URL request manually, I had to first authenticate
via http -- but clearly Aggregate can't do this automatically, so it
reports a failure.
Thus, for the password-change code to work, your current Aggregate login
has to match your security.server.secureChannelType setting. I
have security.server.secureChannelType=ANY_CHANNEL, so I have to log in via
http. Similarly, I expect that if I
set security.server.secureChannelType=REQUIRES_SECURE_CHANNEL and login via
http, I would get the same error. (I will try this since I am now going to
switch to security.server.secureChannelType=REQUIRES_SECURE_CHANNEL.)
This seems like undesirable behavior. (Unless something changed in v1.2, I
must have always happened to change passwords via http.) Do you want me to
log an issue in the system?
Thanks,
Chris
On Friday, July 20, 2012, Christopher Robert wrote:
Hi Mitch,
Thanks for the suggestions.
It works fine if I use the URL directly. As for GWT, I
see gwt-servlet-2.4.0.jar in WEB-INF/lib. After pulling down the new
sources, this time I didn't even bother with Eclipse -- so I did an "mvn
clean" followed by an "mvn install", then cleaned out the entire server
tree, then uploaded the new war contents. Thus, I should be getting
whatever versions of things are specified in the pom.xml's, etc.
I will re-clean, re-build, and re-install, just to make sure that I didn't
accidentally leave some vestige of the old version. Then I'll debug further
and report back.
Thanks again,
Chris
On Friday, July 20, 2012, Mitch S wrote:
For the error message, for some reason the request isn't returning what it
should -- there's no username coming back.
What do you get back if you try the URL directly? The format is:
http://yourhostname/ssl/user-manage-passwords?echo=loopbackstring&username=fred&digestAuthHash=4444
If username "fred" exists, this will set its digest auth hash to 4444 and
return a JSON string like this:
({"username":"fred","status":"OK","echo":"loopbackstring"})
You can verify that it reached the server by looking in the database
_registered_users table -- the DIGEST_AUTH_PASSWORD column for 'fred'
should now be 4444
And the echo string is purely for verifying that this is the response for
the request you entered (it was for debugging).
Of course, all parameters should be URL-encoded.
If that works, then it is a problem in the GWT JSON code. What version of
GWT are you using? I've only built against 2.4. Things might have changed
in 2.5
Mitch
On Thu, Jul 19, 2012 at 1:26 PM, Christopher Robert < chrislrobert@gmail.com> wrote:
Hi Mitch,
security.server.secureChannelType=ANY_CHANNEL and security.server.hostname
is correct as best as I can tell. Also, the error message has the correct
hostname, which implies that it's going to the right place. Is there
something else I can test to confirm the general hypothesis, though?
Something else that should similarly fail if there's something of this ilk?
I have done the following to get ports 80 and 443 to be the public ones:
sudo /sbin/iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT
--to-port 8080
sudo /sbin/iptables -t nat -I PREROUTING -p tcp --dport 443 -j REDIRECT
--to-port 8443
sudo /sbin/service iptables save
[ set proxyPort to 80 and 443 in To
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com <javascript:_e({}, 'cvml',
'mitchellsundt@gmail.com');>