qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Matos <bruno.ma...@paradigmaxis.pt>
Subject Re: [QpidWebBasedGUI]: Login
Date Wed, 06 Feb 2013 10:29:13 GMT
On Ter, 2013-02-05 at 19:14 +0000, Fraser Adams wrote:
> 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?

I tested with Trac and it selects the username text if username doesn't
exist. After that, I went to the code and it calls the equals method on
null if the username doesn't exist. In Authenticator.java line 137
replaced the if clause with 

if (_accountCache.getProperty(username) != null &&

and it works fine.

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

Not yet besides qpid-route.

> 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://'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?

In my local broker I have the default configuration, In my test broker I
have a lot of (exotic) extras... :) and sometimes I can't connect, but I
will make a new thread on this after I'm sure that it's not my problem.

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

Well, it didn't happen again, if it does, I'll tell you and send the

Thank you.

Bruno Matos

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message