Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 9.1peur1
    • Fix Version/s: not determined
    • Component/s: standalone_client
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      4,480

      Description

      The ACC's login dialog is not very smart. To improve it, here are several
      proposals that people might like to see in a future release:

      • The dialog always pops up in the upper left corner of the screen. At least on
        Windows (I can't tell for other desktop environments) this is unusual. To match
        the actual desktop environment's native behaviour as good as possible, I propose
        using setLocationByPlatform(true).
      • A lot of people would be quite happy to have the dialog's username edit field
        defaulted to the operating system's username. It's just so much easier if you do
        not have to repeat your own username all the time.
      • I think it would be very comfortable and do not impose any harm if ACC first
        tries to login using the user's current operating system account and if that is
        rejected, ask for username and password. It's not nice to ask for username and
        password all the time.
      • Reading "Java Look And Feel Design Guidelines Second Edition" might be
        beneficial in completely visually redesigning the dialog: It is just not nice to
        look at. The dialog should be titled "Login" but not "Login for user:" (a colon
        in a title?!), and the labels should just be "Username" and "Passwort" but not
        containt the word "Enter". Also the buttons should not be centered but moved to
        the lower right, and Cancel shouldn't be the larger one. Also it would be really
        nice to have some graphics on the dialog, like the GlassFish logo or (even
        better) the logo found in the client's descriptor. Last but not least, the icon
        shouldn't be the default Java cup.
      • When the password was wrong, it would be good to have some "normal" warning
        message box instead of a stack trace. People getting scared by stack traces and
        call the administrator.

        Activity

        mkarg created issue -
        Hide
        mkarg added a comment -
        • When typing in user name and passwort, users expect that now pressing ENTER
          will invoke OK, but actually it just does nothing. Also users expect that
          pressing ESC will invoke CANCEL, but that doesn't work, too. It seems that
          neither shortcuts nor default buttons are designed. That should be improved.
        Show
        mkarg added a comment - When typing in user name and passwort, users expect that now pressing ENTER will invoke OK, but actually it just does nothing. Also users expect that pressing ESC will invoke CANCEL, but that doesn't work, too. It seems that neither shortcuts nor default buttons are designed. That should be improved.
        Hide
        Hong Zhang added a comment -

        assign to tim to take a look

        Show
        Hong Zhang added a comment - assign to tim to take a look
        Hide
        Tim Quinn added a comment -

        These are really useful suggestions.

        This functionality falls into an interesting overlap between the ACC and
        security, so I cannot speak with 100% authority on this, but I would like to see
        many of your suggestions adopted.

        It turns out that there are also some functional shortcomings in the existing
        dialog box. There are several security callback types that the current
        implementation does not support that we should add.

        A few comments:

        • dialog position - great idea; should be easy
        • default the username to OS username - this will need input from the security
          team as well; as a usability improvement it makes sense. Just to be clear, are
          you suggesting using the current value of the user.name system property? One
          thing we'll need to check into is compatibility of whatever we might do between
          the appclient commmand-line environment and Java Web Start launches.
        • try logging in with the current OS account first - This one might meet some
          resistance. From a security standpoint I'm not sure we'd want to - or
          necessarily could - obtain the current user's password from the OS. And that
          would certainly be platform-specific and, probably, native code, which presents
          a high hurdle.
        • dialog design - Yes indeed. Much room for improvement here. We have had
          several ideas for improving things ourselves and it's good to hear several of
          those confirmed. This includes the default Enter action! We'll need to think
          more about the logo/icon image but that's a good idea as well.
        • As for what happens during authentication failure, this is an area that
          definitely requires working closely with the security team. This has been a
          sore point for some time and there are several forum posts and perhaps an issue
          already opened about this.
        Show
        Tim Quinn added a comment - These are really useful suggestions. This functionality falls into an interesting overlap between the ACC and security, so I cannot speak with 100% authority on this, but I would like to see many of your suggestions adopted. It turns out that there are also some functional shortcomings in the existing dialog box. There are several security callback types that the current implementation does not support that we should add. A few comments: dialog position - great idea; should be easy default the username to OS username - this will need input from the security team as well; as a usability improvement it makes sense. Just to be clear, are you suggesting using the current value of the user.name system property? One thing we'll need to check into is compatibility of whatever we might do between the appclient commmand-line environment and Java Web Start launches. try logging in with the current OS account first - This one might meet some resistance. From a security standpoint I'm not sure we'd want to - or necessarily could - obtain the current user's password from the OS. And that would certainly be platform-specific and, probably, native code, which presents a high hurdle. dialog design - Yes indeed. Much room for improvement here. We have had several ideas for improving things ourselves and it's good to hear several of those confirmed. This includes the default Enter action! We'll need to think more about the logo/icon image but that's a good idea as well. As for what happens during authentication failure, this is an area that definitely requires working closely with the security team. This has been a sore point for some time and there are several forum posts and perhaps an issue already opened about this.
        Hide
        Tim Quinn added a comment -

        (comments from Markus via e-mail appended - with permission)

        > * default the username to OS username - this will need input from the security
        > team as well; as a usability improvement it makes sense. Just to be clear, are
        > you suggesting using the current value of the user.name system property? One
        > thing we'll need to check into is compatibility of whatever we might do between
        > the appclient commmand-line environment and Java Web Start launches.
        >
        Yes my suggestion is to default the content of the JTextField to the user.name
        system propertiy, just for convenience. That string should be completely
        selected by default, so if the user starts to type it automatically removes the
        default. That makes it as easy as possible to the user: Either he just typies
        another name (no need to delete the default first), or he just accepts the
        default by pressing tab to go into the password text field.
        > * try logging in with the current OS account first - This one might meet some
        > resistance. From a security standpoint I'm not sure we'd want to - or
        > necessarily could - obtain the current user's password from the OS. And that
        > would certainly be platform-specific and, probably, native code, which presents
        > a high hurdle.
        >
        The idea was copied from Sybase SQL Anywhere (a mid-size RDBMS system). The
        tools of that software provide a cool feature: When trying to login to the
        database server, the tools first try to pass your Kerberos token (Windows
        internally uses Kerberos, no additional software needed) to the database server.
        The server checks whether your token is valid. If true, you are logged in. If
        not, the tool asks for user name and password based login. That is pretty cool,
        since it is not mutual exclusive between single login and basic login – you can
        have both, but it just tries both methods in a sequence. In fact, it is not
        unsafe, since the administrator can tell for each user account which allowed
        login methods will be accepted.
        > * dialog design - Yes indeed. Much room for improvement here. We have had
        > several ideas for improving things ourselves and it's good to hear several of
        > those confirmed. This includes the default Enter action! We'll need to think
        > more about the logo/icon image but that's a good idea as well.
        >
        People really like to see their own visual stuff be used wherever possible. It
        is just a great experience to deploy your own EAR (including your logos etc.)
        and when logging in get a warm welcome from your very own logo.
        > * As for what happens during authentication failure, this is an area that
        > definitely requires working closely with the security team. This has been a
        > sore point for some time and there are several forum posts and perhaps an issue
        > already opened about this.
        >
        It is just not very smart for the typical non-programmer to see a stack trace
        when he did a typo in the password. People get scared and think something is
        crashed. It's much nicer to tell the user "Hey dummie, there is a security
        problem with your password!".

        Show
        Tim Quinn added a comment - (comments from Markus via e-mail appended - with permission) > * default the username to OS username - this will need input from the security > team as well; as a usability improvement it makes sense. Just to be clear, are > you suggesting using the current value of the user.name system property? One > thing we'll need to check into is compatibility of whatever we might do between > the appclient commmand-line environment and Java Web Start launches. > Yes my suggestion is to default the content of the JTextField to the user.name system propertiy, just for convenience. That string should be completely selected by default, so if the user starts to type it automatically removes the default. That makes it as easy as possible to the user: Either he just typies another name (no need to delete the default first), or he just accepts the default by pressing tab to go into the password text field. > * try logging in with the current OS account first - This one might meet some > resistance. From a security standpoint I'm not sure we'd want to - or > necessarily could - obtain the current user's password from the OS. And that > would certainly be platform-specific and, probably, native code, which presents > a high hurdle. > The idea was copied from Sybase SQL Anywhere (a mid-size RDBMS system). The tools of that software provide a cool feature: When trying to login to the database server, the tools first try to pass your Kerberos token (Windows internally uses Kerberos, no additional software needed) to the database server. The server checks whether your token is valid. If true, you are logged in. If not, the tool asks for user name and password based login. That is pretty cool, since it is not mutual exclusive between single login and basic login – you can have both, but it just tries both methods in a sequence. In fact, it is not unsafe, since the administrator can tell for each user account which allowed login methods will be accepted. > * dialog design - Yes indeed. Much room for improvement here. We have had > several ideas for improving things ourselves and it's good to hear several of > those confirmed. This includes the default Enter action! We'll need to think > more about the logo/icon image but that's a good idea as well. > People really like to see their own visual stuff be used wherever possible. It is just a great experience to deploy your own EAR (including your logos etc.) and when logging in get a warm welcome from your very own logo. > * As for what happens during authentication failure, this is an area that > definitely requires working closely with the security team. This has been a > sore point for some time and there are several forum posts and perhaps an issue > already opened about this. > It is just not very smart for the typical non-programmer to see a stack trace when he did a typo in the password. People get scared and think something is crashed. It's much nicer to tell the user "Hey dummie, there is a security problem with your password!".
        kenaiadmin made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 4480 36084
        Hide
        Tom Mueller added a comment -

        Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

        Show
        Tom Mueller added a comment - Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.
        Tom Mueller made changes -
        Fix Version/s not determined [ 11149 ]
        Fix Version/s V3 [ 10981 ]

          People

          • Assignee:
            Tim Quinn
            Reporter:
            mkarg
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: