qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: [QpidWebBasedGUI]: Login
Date Tue, 05 Feb 2013 19:14:16 GMT
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 

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:


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 
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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message