On 05/02/13 11:28, Bruno Matos wrote:
Hi Fraser,
I've started a new thread to clean history, I hope you don't mind.
No not at all that makes sense. That's actually quite amusingly
appropriate given the nature of the new thread :-D
In the login window, if I use a wrong password it resets all text boxes
(as expected), but if I use a wrong username the browser (chrome) shows
an error page and I have to restart the browser to see the login window
again. (Maybe because it's saving the wrong username in the cache).
At the risk of being slopey shouldered :-) That sounds like it's a
behaviour of the browser(s). How does it behave with other application
logins?
The authentication stuff that I've implemented to date is, ahem, fairly
basic, it uses the org.apache.qpid.restapi.httpserver.Authenticator
classes so I basically do:
server.createContext("/qpid/connection",
qpidserver).setAuthenticator(authenticator);
in the main QpidRestAPI class and the authenticator is an implementation
of com.sun.net.httpserver.BasicAuthenticator.
So the "authentication user interface" such as it is really is just the
standard browser specific dialogue that appears when an HTTP 401 Not
Authorized response gets sent (that's sent automagically by the
BasicAuthenticator class under the covers).
I've just tried the same in Firefox and I'm seeing similar behaviour, so
if I go to the main login and type admin as a user name I can try a
bunch of passwords and it just keeps clearing, but if I type a random
username even with no password at all I get a "The connection was reset".
In Firefox if I do Edit->Preferences->Privacy->clear_all_current_history
It seems to sort things - though not always reliably and I sometimes
have to exit FF and restart.
To be honest I'm not an expert in this, but I'm /fairly convinced/ this
is "just how browsers behave", though I'd have to admit that it's not
terribly friendly :-( I guess that's why a lot of sites use "form based"
login. I quite like using the proper security principal - I'm using that
to help demultiplex, so between that and UUIDs for connection names I've
avoided passing cookies around. I'm not sure of another way to get this
passed by the browser without using the default form. If anyone knows a
good way then I'm all ears as I think that the default dialogue is
pretty ugly (it's OK in mobile Safari, passible in IE and ugly as sin in
Firefox :-)).
Ultimately I'd quite like to fire it up over SSL, a bespoke form might
be OK then, though TBH it'd be quite cool to do something like symmetric
authentication using a client certificate/kerberos, but it's all a bit
tedious and I'm no expert, so it'd be a bit of learning and wasn't high
on my todo list :-)
PS: I'm using RestAPI as substitution for the command line tools
already. Sometimes I still go to the command line, but it's only because
I'm used too.
That's really great to know I'm so pleased!! Thanks for all the feedback
to date, I appreciate it.
Is there anything that you reckon you can do on the command line that
you aren't able to do via the GUI? The only things I can think of relate
to the qpid-route stuff, I *thought* I'd covered off everything else -
but I've been so close to it for so long I'm at risk of not seeing wood
for trees....
Hopefully you've seen my posts on the weird "anonymous" broker
authentication stuff we've chatted about. It looks like we may be seeing
different behaviours there possibly down to different Qpid versions. If
I have a ConnectionURL
amqp://:@QpidJMS/vhost?brokerlist='tcp://0.0.0.0:5672?sasl_mechs='ANONYMOUS''
it's happy on a broker with --auth yes - I don't even need
anonymous:anonymous as username/password, but if I don't include the
sasl_mechs bit the broker isn't happy, so either there's some difference
in how Qpid versions behave here or you've got something extra in
qpidd.conf or the sasl conf?
Either way if I update ConnectionHelper to default to
sasl_mechs='ANONYMOUS' if no username has been supplied then that should
give the same default behaviour as C++ and python URLs.
Did you ever get a chance to try and get to the bottom of the "refresh
time" issue that you'd been seeing. I remain stumped by this and would
love to know how things compare in back to back comparisons with
qpid-queue-stats and qpid-tool. You said in a previous email that you
reckoned qpid-tool was being sluggish too, so that does sort of point to
it being something your end such as a loaded network or loaded broker,
but I'd really love to know. Until I can reproduce it it's going to be
hard to figure out. It'll be interesting to know if you see any
difference for connections configured with and without "Disable Events"
set and what sort of thing you are seeing in your graphs.
Cheers,
Frase
