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 &&
_accountCache.getProperty(username).equals(password))

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

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

Regards,
Thank you.

-- 
Bruno Matos


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