Saving the credentials by browser on login page

Lukas Krejci lkrejci at redhat.com
Wed Sep 26 15:19:28 UTC 2012


It's not the console that let's you save the creds. It's the browser.

The only thing the console can do is to specifically PREVENT the browser from 
doing so (either using some markup or by using a messed up dynamic HTML as we 
do ;) ).

For example access.redhat.com (which I assume you'd agree is very security 
sensitive) doesn't prevent the browser from saving the creds for the login 
page.

I repeat, this is a feature of a browser, not any webapp.

On Wednesday, September 26, 2012 11:11:29 Charles Crouch wrote:
> does the AS7 console let you save cred's?
> 
> ----- Original Message -----
> 
> > Just backing up a step. Do any other competing products in our space
> > do this now?
> > 
> > 
> > 
> > 
> > On Sep 26, 2012, at 7:08 AM, Jiri Kremser <jkremser at redhat.com>
> > 
> > wrote:
> > > Hi,
> > > 
> > >  thanks for responses.
> > > 
> > > "The typical GWT solution (from my email) uses one single form for
> > > the login process."
> > > 
> > > That was my first attempt and I agree it would be simpler. It
> > > worked but the UI was obviously different (in terms of look and
> > > feel), it can be styled by css to look same like SmartGWT, but we
> > > use also form validations and error notification area in the form.
> > > These are supported only by SmartGWT. If it doesn't mind, I can
> > > rewrite it to use the pure gwt for logging in, but I thought we
> > > wanted to move away from the pure GWT components.
> > > 
> > > I am sure the same can be done with SmartGWT.
> > > I didn't find the way. The problem is the SmartGWT don't provide
> > > any functionality for wrapping the existing HTML elements as I've
> > > written few mails ago.
> > > *
> > > http://stackoverflow.com/questions/9935328/wrapping-html-element-by-smar
> > > tgwt-widgets?rq=1 *
> > > http://stackoverflow.com/questions/12564518/wrapping-pre-made-elements-u
> > > sing-smartgwt * http://forums.smartclient.com/showthread.php?t=23739
> > > 
> > > ..and the login form created by SmartGWT is definitely not
> > > recognized by browser as a "login form", so it doesn't provide any
> > > saving options for credentials. No wonder, there are so many
> > > layers of "divs" and the buttons are represented as html tables,
> > > and so on.
> > > 
> > > 
> > > 1) Copying usernames and passwords is risky because the actual
> > > strings will be stored in memory variables.
> > > 
> > > The same thing is happening right now. The SmartGWT form fields are
> > > represented by java script variables and the text from it could be
> > > extracted right now.
> > > Because of the fact the all client code can be fakeable (I hope it
> > > is a word:]), the most security checks including authN and authZ
> > > should be done completely on the server-side. Here is nice video
> > > of GWT security: http://www.youtube.com/watch?v=hKrvY42dw1A. He
> > > shows that obfuscation doesn't solve anything.
> > > 
> > > 2) Having a JSNI method for login is also exploitable. The login
> > > process will be at the fingertips of attackers armed with clever
> > > XSS attacks. This will enable silent login attempts with
> > > absolutely no warning to the user.
> > > 
> > > here is a code sniped from my compiled project (file
> > > 61B0DAF0F7EDA8CBC84C80FE3874EB2A.cache.html, but the name may
> > > 
> > > differ):
> > >  if (statusCode == 200) {
> > >  ...
> > >  
> > >   org_rhq_enterprise_gui_coregui_client_UserSessionManager_login__Ljava_
> > >   lang_String_2Ljava_lang_String_2V(this.org_rhq_enterprise_gui_coregui_
> > >   client_LoginView$9_val$username,> >  
> > >  this.org_rhq_enterprise_gui_coregui_client_LoginView$9_val$password);
> > >  ...
> > >  }
> > > 
> > > What stops me now from calling this function right now with the
> > > current version and why is JSNI login method a problem (btw. my
> > > exposed function has signature doLogin() no params here, the
> > > values are taken from the form).
> > > 
> > > 
> > > JK
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > From: "Lukas Krejci" <lkrejci at redhat.com>
> > > To: rhq-devel at lists.fedorahosted.org
> > > Sent: Wednesday, September 26, 2012 10:53:43 AM
> > > Subject: Re: Saving the credentials by browser on login page
> > > 
> > > On Tuesday, September 25, 2012 17:47:20 Stefan Negrea wrote:
> > >> I am concerned too with the security risk of this proposed
> > >> approach. The
> > >> typical GWT solution (from my email) uses one single form for the
> > >> login
> > >> process. I am sure the same can be done with smartGWT.
> > >> 
> > >> I see two problem with the current proposal:
> > >> 1) The extra copying between the HTML form and smartGWT form is
> > >> exploitable.
> > >> Copying usernames and passwords is risky because the actual
> > >> strings will be
> > >> stored in memory variables.
> > > 
> > > Are they not stored in the HTML form, too? Like
> > > document.getElementById("passwordField").value(); ? If the attacker
> > > can get
> > > himself to manipulate the DOM on the page, he can extract any info
> > > the user
> > > enters, no matter if the form is dynamic or static. And there needs
> > > to be no
> > > copying for that to be possible.
> > > 
> > >> 2) Having a JSNI method for login is also
> > >> exploitable. The login process will be at the fingertips of
> > >> attackers armed
> > >> with clever XSS attacks. This will enable silent login attempts
> > >> with
> > >> absolutely no warning to the user.
> > > 
> > > Yes, the exposure of the login method through JSNI makes the attack
> > > attempts
> > > easier. But the login method has always been there, only with a
> > > slightly more
> > > obfuscated name. Anyone knowing GWT would be able to deduce the
> > > name easily
> > > (like Jirka did when he wrote the JSNI impl).
> > > 
> > >> The solution: use just the HTML form and change the post address
> > >> of that
> > >> form. Instead of showing the smartGWT form on the login page, make
> > >> this
> > >> HTML form visible on the webpage. You should just manipulate the
> > >> DOM to
> > >> change the location of the form in the tree. Rather than making
> > >> the
> > >> solution more complicated (extra layers of forms), we should work
> > >> on
> > >> removing any unnecessary elements/code/variables from the login
> > >> process.
> > >> 
> > >> The idea is to use the browser infrastructure for the entire
> > >> process. The
> > >> security concerns will then shift from our application to the
> > >> browser
> > >> itself. And that is an acceptable security risk.
> > > 
> > > +1, that would be the ideal solution.
> > > 
> > >> Stefan Negrea
> > >> 
> > >> ----- Original Message -----
> > >> 
> > >>> From: "Lukas Krejci" <lkrejci at redhat.com>
> > >>> To: rhq-devel at lists.fedorahosted.org
> > >>> Sent: Tuesday, September 25, 2012 10:44:13 AM
> > >>> Subject: Re: Saving the credentials by browser on login page
> > >>> 
> > >>> What about constrained environments where users can't install
> > >>> their
> > >>> own
> > >>> browser addons?
> > >>> 
> > >>> I mean, c'mon. This is a very standard browser feature we're
> > >>> talking
> > >>> about
> > >>> here that we're preventing.
> > >>> 
> > >>> I personally can see no security threat to having a static HTML
> > >>> form
> > >>> to do the
> > >>> logging in. The server endpoints are still the same, the data
> > >>> passed
> > >>> to them
> > >>> is still the same. It's the server that does the authentication
> > >>> and
> > >>> no server
> > >>> logic is being changed here. Also, no data is stored on the
> > >>> client
> > >>> side.
> > >>> 
> > >>> Wrt XSS - maybe the exposure of the doLogin() method makes the
> > >>> potential
> > >>> breach a bit easier but that method always existed and was being
> > >>> translated
> > >>> into javascript by GWT compiler. So all Jirka did there was that
> > >>> he
> > >>> changed a
> > >>> a javascript function to have a "nicer name".
> > >>> 
> > >>> I am all for having another pair(s) of eyes on this, but I think
> > >>> we're being a
> > >>> bit paranoid here.
> > >>> 
> > >>> Take a look at the diff
> > >>> http://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?h=jkremser/loginS
> > >>> avin
> > >>> g&id=36668b80ee7f8caef63bc3b6bdc10768038031e2
> > >>> 
> > >>> There is no new functionality there - it's just another way of
> > >>> calling the
> > >>> same method.
> > >>> 
> > >>> On Tuesday, September 25, 2012 11:11:41 John Mazzitelli wrote:
> > >>>> IMO, just publish the grease monkey script and be done with it.
> > >>>> 
> > >>>> ----- Original Message -----
> > >>>> 
> > >>>>> I was under the impression that we had already decided that
> > >>>>> this
> > >>>>> was
> > >>>>> a risky proposition? Typically, something like this would get
> > >>>>> flagged in a code audit (manual or automated). The thing with
> > >>>>> security is that you may not fully understand what you are
> > >>>>> exposing
> > >>>>> as dangerous until you get hacked.   As JON can control other
> > >>>>> servers it could quickly become a severe issue for a customer.
> > >>>>> Once
> > >>>>> a product gets tainted by a serious security issue it is very
> > >>>>> hard
> > >>>>> to recover from that kind of publicity.
> > >>>>> 
> > >>>>> Is there a Red Hat security team that can advise on this?
> > >>>>> Perhaps
> > >>>>> standard practices...
> > >>>>> 
> > >>>>> 
> > >>>>> -- Mike
> > >>>>> 
> > >>>>> On Sep 25, 2012, at 6:59 AM, Jiri Kremser <jkremser at redhat.com>
> > >>>>> 
> > >>>>> wrote:
> > >>>>>> Hi,
> > >>>>>> 
> > >>>>>> I've implemented the issue using the hidden form hack. I've
> > >>>>>> found
> > >>>>>> only one example of this on the web
> > >>>>>> (http://borglin.net/gwt-project/?page_id=467, great blog
> > >>>>>> btw.).
> > >>>>>> However, the example doesn't use the SmartGWT but pure GWT.
> > >>>>>> They
> > >>>>>> actually use directly the hidden form for logging in by
> > >>>>>> calling
> > >>>>>> FormPanel.wrap(Document.get().getElementById(LOGINFORM_ID))
> > >>>>>> and
> > >>>>>> rendering it. It wraps an existing element with pure GWT
> > >>>>>> component. SmartGWT, unfortunately, doesn't support such
> > >>>>>> functionality (I tried smartclient forum, stackoverflow and
> > >>>>>> JavaDoc :]), so I had to "mirror" the values between the two
> > >>>>>> forms (the hidden one and the SmartGWT one), and when
> > >>>>>> submitting
> > >>>>>> the visible form, the submit is invoked on the hidden form too
> > >>>>>> which calls JSNI method for logging in.
> > >>>>>> 
> > >>>>>> It works without problems in Chrome21 and IE8. FF 10 asks for
> > >>>>>> saving the credentials, but fills it only if the user access
> > >>>>>> the
> > >>>>>> page by pressing the logout (=> don't fill it if you access
> > >>>>>> the
> > >>>>>> page directly, strange).
> > >>>>>> 
> > >>>>>> The changes are pushed in git branch jkremser/loginSaving
> > >>>>>> 
> > >>>>>> Concerning security:
> > >>>>>> * I had to expose the "doLogin()" function via JSNI in order
> > >>>>>> to
> > >>>>>> be
> > >>>>>> able to call it from Java Script. doLogin() reads the
> > >>>>>> credentials
> > >>>>>> from the hidden form and with them performs the
> > >>>>>> login(user,pass)
> > >>>>>> and subsequently sends POST to portal's struts action
> > >>>>>> (j_security_check.do). The only risk, I can see, is that
> > >>>>>> attacker
> > >>>>>> can make the hidden form visible and type the credentials
> > >>>>>> directly
> > >>>>>> to it (or from JavaScript) bypassing the form validation on
> > >>>>>> the
> > >>>>>> proper login form. However, right now we validate only if the
> > >>>>>> username and password is not "".
> > >>>>>> 
> > >>>>>> * Credentials are NOT stored by the application logic. Browser
> > >>>>>> asks
> > >>>>>> the user and stores it if he/she confirms, like many other web
> > >>>>>> application. Here, one can say, it is not a good practice and
> > >>>>>> we
> > >>>>>> should avoid it. We can discuss it. It depends, If the online
> > >>>>>> banking app suggests me saving the password I would probably
> > >>>>>> change the bank. I am not saying RHQ is not so critical (it
> > >>>>>> may
> > >>>>>> be
> > >>>>>> in many cases), but don't forget it is only option. User can
> > >>>>>> turn
> > >>>>>> it off or use it, it is up to him. Same thing holds for
> > >>>>>> securing
> > >>>>>> the webapp with SSL + certificate. Because without running it
> > >>>>>> on
> > >>>>>> SSL it is quite funny to talk about security aspects, and send
> > >>>>>> the
> > >>>>>> password in plain text :]
> > >>>>>> 
> > >>>>>> * Other risk may come from the fact the login form (the hidden
> > >>>>>> variant) is now present in the static html content, so if the
> > >>>>>> webapp is hosted on public IP, some crawler or bot can
> > >>>>>> potentially
> > >>>>>> mark this page as hackable. Counterargument could be that the
> > >>>>>> same
> > >>>>>> thing is possible now after evaluating the JavaScript.
> > >>>>>> 
> > >>>>>> 
> > >>>>>> I've also prepared the Grease Monkey script for FF and placed
> > >>>>>> it to
> > >>>>>> /etc/dev-utils. It fills the credentials if you press alt+c
> > >>>>>> and
> > >>>>>> it
> > >>>>>> works well also in Chrome with Tampermonkey add-on. I haven't
> > >>>>>> tried it with the IE yet.
> > >>>>>> 
> > >>>>>> JK
> > >>>>>> 
> > >>>>>> 
> > >>>>>> ----- Original Message -----
> > >>>>>> From: "Stefan Negrea" <snegrea at redhat.com>
> > >>>>>> To: rhq-devel at lists.fedorahosted.org
> > >>>>>> Sent: Wednesday, September 5, 2012 9:27:28 PM
> > >>>>>> Subject: Re: Saving the credentials by browser on login page
> > >>>>>> 
> > >>>>>> Hello,
> > >>>>>> 
> > >>>>>> 
> > >>>>>> This is a known issue with GWT applications and the fix is
> > >>>>>> simple.
> > >>>>>> This section explains well the strategy:
> > >>>>>> http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSec
> > >>>>>> u
> > >>>>>> rity
> > >>>>>> FAQ#auto-complete_and_GWT
> > >>>>>> 
> > >>>>>> 
> > >>>>>> Storing passwords or usernames in cookies is dangerous!
> > >>>>>> 
> > >>>>>> 
> > >>>>>> Thank you,
> > >>>>>> Stefan
> > >>>>>> 
> > >>>>>> ----- Original Message -----
> > >>>>>> 
> > >>>>>>> From: "Lukas Krejci" <lkrejci at redhat.com>
> > >>>>>>> To: rhq-devel at lists.fedorahosted.org
> > >>>>>>> Sent: Friday, August 31, 2012 8:16:53 AM
> > >>>>>>> Subject: Re: Saving the credentials by browser on login page
> > >>>>>>> 
> > >>>>>>> On Friday, August 31, 2012 09:03:58 John Mazzitelli wrote:
> > >>>>>>>> I would disagree that it is a "rather big" usability issue.
> > >>>>>>>> Relative to all
> > >>>>>>>> the other issues in the UI, I would put this low on the
> > >>>>>>>> list.
> > >>>>>>> 
> > >>>>>>> Well, this one is right in the face of everybody using RHQ.
> > >>>>>>> It's
> > >>>>>>> the
> > >>>>>>> first
> > >>>>>>> thing they see and there's no going around that.
> > >>>>>>> Something along the lines of "they can't get right even such
> > >>>>>>> a
> > >>>>>>> simple
> > >>>>>>> thing as
> > >>>>>>> password completion? They suck!"
> > >>>>>>> 
> > >>>>>>>> I would agree that if some solution can simply enable the
> > >>>>>>>> browser
> > >>>>>>>> to do "its
> > >>>>>>>> thing", that would be nice. But I heard things like "storing
> > >>>>>>>> the
> > >>>>>>>> password
> > >>>>>>>> in a cookie" and things like that - that's what I say we
> > >>>>>>>> should
> > >>>>>>>> not
> > >>>>>>>> even
> > >>>>>>>> entertain the thought.
> > >>>>>>> 
> > >>>>>>> +100
> > >>>>>>> 
> > >>>>>>>> If there is some magic to put some hidden dummy form
> > >>>>>>>> in the page to trick the browser to remember the info using
> > >>>>>>>> its
> > >>>>>>>> normal
> > >>>>>>>> mechanisms, then that would be different.
> > >>>>>>> 
> > >>>>>>> I actually thought this was the plan.
> > >>>>>>> 
> > >>>>>>>> But again, relative to everything else, this would be low on
> > >>>>>>>> the
> > >>>>>>>> list to
> > >>>>>>>> implement IMO as we've got lots of other stuff that would be
> > >>>>>>>> higher
> > >>>>>>>> priority (is there even a BZ on this?). As Jiri mentioned
> > >>>>>>>> earlier,
> > >>>>>>>> for
> > >>>>>>>> devs, it would probably be nice to have some a greasemonkey
> > >>>>>>>> script
> > >>>>>>>> to help
> > >>>>>>>> out here. That would be a good solution for devs whose
> > >>>>>>>> fingers
> > >>>>>>>> hurt
> > >>>>>>>> typing
> > >>>>>>>> rhqadmin :}
> > >>>>>>>> 
> > >>>>>>>> ----- Original Message -----
> > >>>>>>>> 
> > >>>>>>>>> Well, this whole thing is not about us implementing some
> > >>>>>>>>> convenience
> > >>>>>>>>> for the users but about us NOT PREVENTING a convenience
> > >>>>>>>>> function
> > >>>>>>>>> that browsers implement.
> > >>>>>>>>> 
> > >>>>>>>>> I see a big difference there. It is a standard feature of
> > >>>>>>>>> all
> > >>>>>>>>> browsers to offer to "save passwords" on any page where
> > >>>>>>>>> people
> > >>>>>>>>> put
> > >>>>>>>>> in credentials. This is not possible on RHQ login page. It
> > >>>>>>>>> is
> > >>>>>>>>> not
> > >>>>>>>>> for us to answer the security aspects of this solution or
> > >>>>>>>>> to
> > >>>>>>>>> try
> > >>>>>>>>> to
> > >>>>>>>>> be "smarter" than the browsers are.
> > >>>>>>>>> 
> > >>>>>>>>> For me this is a rather big usability issue.
> > >>>>>>>>> 
> > >>>>>>>>> Lukas
> > >>>>>>>>> 
> > >>>>>>>>> ----- Original Message -----
> > >>>>>>>>> 
> > >>>>>>>>>> From: "John Mazzitelli" <mazz at redhat.com>
> > >>>>>>>>>> To: rhq-devel at lists.fedorahosted.org
> > >>>>>>>>>> Sent: Thursday, August 30, 2012 6:16:55 PM
> > >>>>>>>>>> Subject: Re: Saving the credentials by browser on login
> > >>>>>>>>>> page
> > >>>>>>>>>> 
> > >>>>>>>>>> IMO, I would recommend staying far away from doing
> > >>>>>>>>>> anything
> > >>>>>>>>>> "for
> > >>>>>>>>>> convenience" that has anything to do with security. This
> > >>>>>>>>>> is
> > >>>>>>>>>> asking
> > >>>>>>>>>> for trouble.
> > >>>>>>>>>> 
> > >>>>>>>>>> It is best if something like "my password was hacked" can
> > >>>>>>>>>> be
> > >>>>>>>>>> 100%
> > >>>>>>>>>> blamed on, say, the browser or a weak password (as opposed
> > >>>>>>>>>> to
> > >>>>>>>>>> it
> > >>>>>>>>>> being blamed on RHQ :-)
> > >>>>>>>>>> 
> > >>>>>>>>>> Seriously, the minute you start attempting to implement
> > >>>>>>>>>> something
> > >>>>>>>>>> around security like this, you WILL get people looking
> > >>>>>>>>>> very
> > >>>>>>>>>> closely
> > >>>>>>>>>> at your code and dollars to donuts, some hole some where
> > >>>>>>>>>> will
> > >>>>>>>>>> be
> > >>>>>>>>>> found (which I can attest to with the "convenience"
> > >>>>>>>>>> feature
> > >>>>>>>>>> we
> > >>>>>>>>>> had
> > >>>>>>>>>> for the agent token stuff a while ago that we ended up
> > >>>>>>>>>> removing).
> > >>>>>>>>>> 
> > >>>>>>>>>> As the guy on that old TV cop show used to say, "Let's be
> > >>>>>>>>>> careful
> > >>>>>>>>>> out
> > >>>>>>>>>> there!"
> > >>>>>>>>>> 
> > >>>>>>>>>> P.S. Your fingers learn to type "rhqadmin" really fast
> > >>>>>>>>>> after
> > >>>>>>>>>> you do
> > >>>>>>>>>> it for a while. :)
> > >>>>>>>>>> 
> > >>>>>>>>>> ----- Original Message -----
> > >>>>>>>>>> 
> > >>>>>>>>>>> IMO storing the password is a poor choice (even if done
> > >>>>>>>>>>> properly)
> > >>>>>>>>>>> and
> > >>>>>>>>>>> may not be welcomed as a feature by some organizations.
> > >>>>>>>>>>> However,
> > >>>>>>>>>>> storing the user name might be nice but even that should
> > >>>>>>>>>>> not
> > >>>>>>>>>>> be
> > >>>>>>>>>>> in
> > >>>>>>>>>>> plain text. Here is another link to complement the link
> > >>>>>>>>>>> below:
> > >>>>>>>>>>> http://crackstation.net/hashing-security.htm
> > >>>>>>>>>>> 
> > >>>>>>>>>>> 
> > >>>>>>>>>>> Obviously this is a sensitive area.
> > >>>>>>>>>>> 
> > >>>>>>>>>>> 
> > >>>>>>>>>>> 
> > >>>>>>>>>>> HTML5 local storage is another option to cookies. Cookies
> > >>>>>>>>>>> get
> > >>>>>>>>>>> sent
> > >>>>>>>>>>> with every request including images and gwt-rpc. This way
> > >>>>>>>>>>> the
> > >>>>>>>>>>> username would never leave the client (except for the
> > >>>>>>>>>>> actual
> > >>>>>>>>>>> login).
> > >>>>>>>>>>> FF and IE9 have support for it and there is a polyfill
> > >>>>>>>>>>> for
> > >>>>>>>>>>> web
> > >>>>>>>>>>> storage in IE8.
> > >>>>>>>>>>> 
> > >>>>>>>>>>> 
> > >>>>>>>>>>> 
> > >>>>>>>>>>> 
> > >>>>>>>>>>> 
> > >>>>>>>>>>> 
> > >>>>>>>>>>> 
> > >>>>>>>>>>> 
> > >>>>>>>>>>> On Aug 30, 2012, at 7:36 AM, Jiri Kremser <
> > >>>>>>>>>>> jkremser at redhat.com >
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>> 
> > >>>>>>>>>>> 
> > >>>>>>>>>>> Hi,
> > >>>>>>>>>>> I've found this page [1] and I am trying to get this idea
> > >>>>>>>>>>> working.
> > >>>>>>>>>>> Lukas suggested the values can be obtained from the
> > >>>>>>>>>>> hidden
> > >>>>>>>>>>> form
> > >>>>>>>>>>> by
> > >>>>>>>>>>> JS (DOM manipulation). But there will be probably
> > >>>>>>>>>>> necessary
> > >>>>>>>>>>> to do
> > >>>>>>>>>>> the other way i.e. to fill the form and submit it with
> > >>>>>>>>>>> some
> > >>>>>>>>>>> kind
> > >>>>>>>>>>> of
> > >>>>>>>>>>> no-op somehow on the background to let the browser to
> > >>>>>>>>>>> store
> > >>>>>>>>>>> it.
> > >>>>>>>>>>> Other option could be to use the cookies
> > >>>>>>>>>>> com.google.gwt.user.client.Cookies.{get|set}Value() but I
> > >>>>>>>>>>> am
> > >>>>>>>>>>> not
> > >>>>>>>>>>> sure about storing the password in plaintext somewhere in
> > >>>>>>>>>>> the
> > >>>>>>>>>>> cookie
> > >>>>>>>>>>> without asking the user.
> > >>>>>>>>>>> 
> > >>>>>>>>>>> Browser does basically the same, but at least it asks :]
> > >>>>>>>>>>> Yes, but this is not secure either.
> > >>>>>>>>>>> 
> > >>>>>>>>>>> 
> > >>>>>>>>>>> 
> > >>>>>>>>>>> 
> > >>>>>>>>>>> 
> > >>>>>>>>>>> [1]
> > >>>>>>>>>>> http://code.google.com/p/google-web-toolkit-incubator/wiki/Log
> > >>>>>>>>>>> i
> > >>>>>>>>>>> nSec
> > >>>>>>>>>>> uri
> > >>>>>>>>>>> tyFAQ#auto-complete_and_GWT
> > >>>>>>>>>>> _______________________________________________
> > >>>>>>>>>>> rhq-devel mailing list
> > >>>>>>>>>>> rhq-devel at lists.fedorahosted.org
> > >>>>>>>>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > >>>>>>>>>>> 
> > >>>>>>>>>>> 
> > >>>>>>>>>>> _______________________________________________
> > >>>>>>>>>>> rhq-devel mailing list
> > >>>>>>>>>>> rhq-devel at lists.fedorahosted.org
> > >>>>>>>>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > >>>>>>>>>> 
> > >>>>>>>>>> _______________________________________________
> > >>>>>>>>>> rhq-devel mailing list
> > >>>>>>>>>> rhq-devel at lists.fedorahosted.org
> > >>>>>>>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > >>>>>>>>> 
> > >>>>>>>>> _______________________________________________
> > >>>>>>>>> rhq-devel mailing list
> > >>>>>>>>> rhq-devel at lists.fedorahosted.org
> > >>>>>>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > >>>>>>>> 
> > >>>>>>>> _______________________________________________
> > >>>>>>>> rhq-devel mailing list
> > >>>>>>>> rhq-devel at lists.fedorahosted.org
> > >>>>>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > >>>>>>> 
> > >>>>>>> _______________________________________________
> > >>>>>>> rhq-devel mailing list
> > >>>>>>> rhq-devel at lists.fedorahosted.org
> > >>>>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > >>>>>> 
> > >>>>>> _______________________________________________
> > >>>>>> rhq-devel mailing list
> > >>>>>> rhq-devel at lists.fedorahosted.org
> > >>>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > >>>>>> _______________________________________________
> > >>>>>> rhq-devel mailing list
> > >>>>>> rhq-devel at lists.fedorahosted.org
> > >>>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > >>>>> 
> > >>>>> _______________________________________________
> > >>>>> rhq-devel mailing list
> > >>>>> rhq-devel at lists.fedorahosted.org
> > >>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > >>>> 
> > >>>> _______________________________________________
> > >>>> rhq-devel mailing list
> > >>>> rhq-devel at lists.fedorahosted.org
> > >>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > >>> 
> > >>> _______________________________________________
> > >>> rhq-devel mailing list
> > >>> rhq-devel at lists.fedorahosted.org
> > >>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > >> 
> > >> _______________________________________________
> > >> rhq-devel mailing list
> > >> rhq-devel at lists.fedorahosted.org
> > >> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > > 
> > > _______________________________________________
> > > rhq-devel mailing list
> > > rhq-devel at lists.fedorahosted.org
> > > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > > _______________________________________________
> > > rhq-devel mailing list
> > > rhq-devel at lists.fedorahosted.org
> > > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > 
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list