Is the weak NTLM v* authentication support in ZAP due to the fact that it
is built on Paros? I have always had a problem with the missing or lacking
support for NTLM authentication in Paros. Is this a existing feature
request? or can be added?
Also, I have submitted a feature request to mask the passwords on the
Authentication settings page.
On Friday, 21 September 2012 16:23:12 UTC+1, prasad wrote:
> Is the weak NTLM v* authentication support in ZAP due to the fact that it > is built on Paros? I have always had a problem with the missing or lacking > support for NTLM authentication in Paros. Is this a existing feature > request? or can be added?
> Also, I have submitted a feature request to mask the passwords on the > Authentication settings page.
On Fri, Sep 21, 2012 at 12:03 PM, psiinon <psii...@gmail.com> wrote:
> Yes :)
> I cant see an existing request for it, but feel free to add it<http://code.google.com/p/zaproxy/issues/entry>
> !
> I must admit I dont do any assessments on apps that use NTLM, but it would
> be really good for ZAP to support it properly.
> That could be a useful project<http://code.google.com/p/zaproxy/wiki/Projects>?
> And good suggestion for the passwords :)
> Many thanks,
> Simon
> On Friday, 21 September 2012 16:23:12 UTC+1, prasad wrote:
>> Is the weak NTLM v* authentication support in ZAP due to the fact that it
>> is built on Paros? I have always had a problem with the missing or lacking
>> support for NTLM authentication in Paros. Is this a existing feature
>> request? or can be added?
>> Also, I have submitted a feature request to mask the passwords on the
>> Authentication settings page.
>> On Friday, 21 September 2012 16:23:12 UTC+1, prasad wrote:
>>> Is the weak NTLM v* authentication support in ZAP due to the fact that >>> it is built on Paros? I have always had a problem with the missing or >>> lacking support for NTLM authentication in Paros. Is this a existing >>> feature request? or can be added?
>>> Also, I have submitted a feature request to mask the passwords on the >>> Authentication settings page.
Would there be any objection to changing the look and feel of the
authentication options panel? The current one uses AbstractTable and model
is not very flexible from what I could deduce. I would like to make the
table more dynamic enabling users to add and delete authentication options
quickly and easily. I have some ideas but want to get the pulse of the
group.
>>> On Friday, 21 September 2012 16:23:12 UTC+1, prasad wrote:
>>>> Is the weak NTLM v* authentication support in ZAP due to the fact that
>>>> it is built on Paros? I have always had a problem with the missing or
>>>> lacking support for NTLM authentication in Paros. Is this a existing
>>>> feature request? or can be added?
>>>> Also, I have submitted a feature request to mask the passwords on the
>>>> Authentication settings page.
Go for it! I dont think thats changed since Paros, so is due for an overhaul ;) We actually use that type of table in other options panels as well, and I agree its not ideal. If you come up with a better one then we should roll it out to those pages as well :)
On Wednesday, 26 September 2012 18:31:29 UTC+1, prasad wrote:
> Would there be any objection to changing the look and feel of the > authentication options panel? The current one uses AbstractTable and model > is not very flexible from what I could deduce. I would like to make the > table more dynamic enabling users to add and delete authentication options > quickly and easily. I have some ideas but want to get the pulse of the > group.
> Any advice would be appreciated.
> [ ~ Prasad | @prasadshenoy ~]
> On Sat, Sep 22, 2012 at 4:07 AM, psiinon <psi...@gmail.com <javascript:>>wrote:
>> I've assigned the issue to you - go for it!
>> On Friday, 21 September 2012 18:05:48 UTC+1, prasad wrote:
>>> I would like to work on the password masking issue item.
>>> [ ~ Prasad | @prasadshenoy ~]
>>> On Fri, Sep 21, 2012 at 12:03 PM, psiinon <psi...@gmail.com> wrote:
>>>> On Friday, 21 September 2012 16:23:12 UTC+1, prasad wrote:
>>>>> Is the weak NTLM v* authentication support in ZAP due to the fact that >>>>> it is built on Paros? I have always had a problem with the missing or >>>>> lacking support for NTLM authentication in Paros. Is this a existing >>>>> feature request? or can be added?
>>>>> Also, I have submitted a feature request to mask the passwords on the >>>>> Authentication settings page.
If I am understanding you correctly, regarding the table model, you only need to implement the methods to add and remove the *HostAuthentication*(s) in the class *OptionsAuthenticationTableModel*.
Curiously, I'm about to finish some changes on how multiple related options are managed (which includes the management of the host authentication) and other details regarding the usability of all the options. Currently there are several ways, which can be grouped in 3 categories, on how those options are managed. All of them have some issues that impair the usability, from minor to greater: 1) The options are added, removed and edited directly in the table (example: "Session properties" > "Exclude from proxy"). The main problems are: - to remove an option you have to delete the contents of the cell; - (a special annoying one) when editing the options if the cell doesn't loose the focus and you close the dialogue the option doesn't get updated; - there's no way to temporarily disable an option (not related to how the management is done, but it's worth remarking it, as most of the multiple related options, if not all, should provide a way to enable/disable them); - it may happen that the last row is not always shown immediately to allow the addition of a new entry; 2) The options are added, edited and removed with buttons, the fields of those options are shown beneath the table listing the options (example: "Options" > "Applications"). There are minor problems related to how the buttons work and the fields being always editable. - If by mistake you press the wrong button (pressing "new" again) it will result in a lose of the additions; - the fields are not updated if the keyboard is used (not related to the management, but it's worth pointing, as this is a usability detail that should be taken in consideration); 3) The options are managed in a text area, this is, by far, the least usable (example: "Options" > "Connections" > "Skip IP addresses (...)" text area). There's no need to say too much about this way (it, almost, speaks for itself), the user has to manually select the correct option to remove it, which can be hard to pinpoint if you have a lot of those and there's no way to disable an entry.
Not all the issues are described, but, more or less, the most relevant to the ways of management, are.
The changes are an attempt to normalise how the management of multiple related options is done throughout ZAP, so, hopefully, the user doesn't have to jump from a way of doing it to another one completely different. It should also allow the user to specify some details of those options, in the case of the "Exclude from proxy", there should be an easy way to specify an URL in plain text without the need to manually "quote" the "regular expression", more over it allows to introduce other conditions not restricted to a specific component of the message like the URL (may be useful if the user wants to exclude files that are greater than a specific size (determined through the "Content-Length" header field)).
Some of the other details regarding the usability of all the options: - When an option is disabled, other options that depend on the disabled option shouldn't be reset. If the user only wanted to disable temporarily the option, he won't need to fill all the fields again (example: "Options"
> "Connections" > "Use an outgoing proxy server" if it is unchecked the
"Address", "Port" and "Skip IP addresses (...)" are reset); - Addition of a button to reset the options to default values. - The components should resize correctly when the dialogue is resized (example: "Options" > "Connections" > "Skip IP addresses (...)" the text area doesn't resize as most as it should).
I also want to allow the user to maximise the "Options" dialogue.
I was going to commit the changes (when ready) without asking about the changes to the develop group, as there are much more advantages to what is being done now that it seems to me that it's a natural change and that it inevitably would happen (there are some issue(s) about the usability of some options).
But as this subject as been brought here, I've attached a working example on what the management will look like (if everyone agrees with it). If anyone wants to see it and give some feedback, it would be greatly appreciated.
On Wednesday, September 26, 2012 6:31:29 PM UTC+1, prasad wrote:
> Would there be any objection to changing the look and feel of the > authentication options panel? The current one uses AbstractTable and model > is not very flexible from what I could deduce. I would like to make the > table more dynamic enabling users to add and delete authentication options > quickly and easily. I have some ideas but want to get the pulse of the > group.
> Any advice would be appreciated.
> [ ~ Prasad | @prasadshenoy ~]
> On Sat, Sep 22, 2012 at 4:07 AM, psiinon <psi...@gmail.com <javascript:>>wrote:
>> I've assigned the issue to you - go for it!
>> On Friday, 21 September 2012 18:05:48 UTC+1, prasad wrote:
>>> I would like to work on the password masking issue item.
>>> [ ~ Prasad | @prasadshenoy ~]
>>> On Fri, Sep 21, 2012 at 12:03 PM, psiinon <psi...@gmail.com> wrote:
>>>> On Friday, 21 September 2012 16:23:12 UTC+1, prasad wrote:
>>>>> Is the weak NTLM v* authentication support in ZAP due to the fact that >>>>> it is built on Paros? I have always had a problem with the missing or >>>>> lacking support for NTLM authentication in Paros. Is this a existing >>>>> feature request? or can be added?
>>>>> Also, I have submitted a feature request to mask the passwords on the >>>>> Authentication settings page.
On Friday, 28 September 2012 01:14:52 UTC+1, thc202 wrote:
> Hi.
> If I am understanding you correctly, regarding the table model, you only > need to implement the methods to add and remove the *HostAuthentication*(s) > in the class *OptionsAuthenticationTableModel*.
> Curiously, I'm about to finish some changes on how multiple related > options are managed (which includes the management of the host > authentication) and other details regarding the usability of all the > options. > Currently there are several ways, which can be grouped in 3 categories, on > how those options are managed. All of them have some issues that impair the > usability, from minor to greater: > 1) The options are added, removed and edited directly in the table > (example: "Session properties" > "Exclude from proxy"). The main problems > are: > - to remove an option you have to delete the contents of the cell; > - (a special annoying one) when editing the options if the cell doesn't > loose the focus and you close the dialogue the option doesn't get updated; > - there's no way to temporarily disable an option (not related to how > the management is done, but it's worth remarking it, as most of the > multiple related options, if not all, should provide a way to > enable/disable them); > - it may happen that the last row is not always shown immediately to > allow the addition of a new entry; > 2) The options are added, edited and removed with buttons, the fields of > those options are shown beneath the table listing the options (example: > "Options" > "Applications"). There are minor problems related to how the > buttons work and the fields being always editable. > - If by mistake you press the wrong button (pressing "new" again) it > will result in a lose of the additions; > - the fields are not updated if the keyboard is used (not related to the > management, but it's worth pointing, as this is a usability detail that > should be taken in consideration); > 3) The options are managed in a text area, this is, by far, the least > usable (example: "Options" > "Connections" > "Skip IP addresses (...)" text > area). There's no need to say too much about this way (it, almost, speaks > for itself), the user has to manually select the correct option to remove > it, which can be hard to pinpoint if you have a lot of those and there's no > way to disable an entry.
> Not all the issues are described, but, more or less, the most relevant to > the ways of management, are.
> The changes are an attempt to normalise how the management of multiple > related options is done throughout ZAP, so, hopefully, the user doesn't > have to jump from a way of doing it to another one completely different. It > should also allow the user to specify some details of those options, in the > case of the "Exclude from proxy", there should be an easy way to specify an > URL in plain text without the need to manually "quote" the "regular > expression", more over it allows to introduce other conditions not > restricted to a specific component of the message like the URL (may be > useful if the user wants to exclude files that are greater than a specific > size (determined through the "Content-Length" header field)).
> Some of the other details regarding the usability of all the options: > - When an option is disabled, other options that depend on the disabled > option shouldn't be reset. If the user only wanted to disable temporarily > the option, he won't need to fill all the fields again (example: "Options" > > "Connections" > "Use an outgoing proxy server" if it is unchecked the > "Address", "Port" and "Skip IP addresses (...)" are reset); > - Addition of a button to reset the options to default values. > - The components should resize correctly when the dialogue is resized > (example: "Options" > "Connections" > "Skip IP addresses (...)" the text > area doesn't resize as most as it should).
> I also want to allow the user to maximise the "Options" dialogue.
> I was going to commit the changes (when ready) without asking about the > changes to the develop group, as there are much more advantages to what is > being done now that it seems to me that it's a natural change and that it > inevitably would happen (there are some issue(s) about the usability of > some options).
> But as this subject as been brought here, I've attached a working example > on what the management will look like (if everyone agrees with it). If > anyone wants to see it and give some feedback, it would be greatly > appreciated.
> Best regards.
> On Wednesday, September 26, 2012 6:31:29 PM UTC+1, prasad wrote:
>> Would there be any objection to changing the look and feel of the >> authentication options panel? The current one uses AbstractTable and model >> is not very flexible from what I could deduce. I would like to make the >> table more dynamic enabling users to add and delete authentication options >> quickly and easily. I have some ideas but want to get the pulse of the >> group.
>> Any advice would be appreciated.
>> [ ~ Prasad | @prasadshenoy ~]
>> On Sat, Sep 22, 2012 at 4:07 AM, psiinon <psi...@gmail.com> wrote:
>>> I've assigned the issue to you - go for it!
>>> On Friday, 21 September 2012 18:05:48 UTC+1, prasad wrote:
>>>> I would like to work on the password masking issue item.
>>>> [ ~ Prasad | @prasadshenoy ~]
>>>> On Fri, Sep 21, 2012 at 12:03 PM, psiinon <psi...@gmail.com> wrote:
>>>>> On Friday, 21 September 2012 16:23:12 UTC+1, prasad wrote:
>>>>>> Is the weak NTLM v* authentication support in ZAP due to the fact >>>>>> that it is built on Paros? I have always had a problem with the missing or >>>>>> lacking support for NTLM authentication in Paros. Is this a existing >>>>>> feature request? or can be added?
>>>>>> Also, I have submitted a feature request to mask the passwords on the >>>>>> Authentication settings page.
This is very timely. I was knee deep into the authentication options panel
already :). All the points you made for Option 1 directly apply to the
Authentication panel. The JTable implementation is very rigid so I started
looking at some other things but couldn't find anything great. Will check
out your changes and opine shortly.
On Fri, Sep 28, 2012 at 3:57 AM, psiinon <psii...@gmail.com> wrote:
> Awesome!
> This has been long overdue, but also a significant undertaking that I've
> not been able to face looking at ;)
> I'll have a play with your changes as soon as I get a chance.
> Many thanks,
> Simon
> On Friday, 28 September 2012 01:14:52 UTC+1, thc202 wrote:
>> Hi.
>> If I am understanding you correctly, regarding the table model, you only
>> need to implement the methods to add and remove the *HostAuthentication*(s)
>> in the class *OptionsAuthenticationTableModel*.
>> Curiously, I'm about to finish some changes on how multiple related
>> options are managed (which includes the management of the host
>> authentication) and other details regarding the usability of all the
>> options.
>> Currently there are several ways, which can be grouped in 3 categories,
>> on how those options are managed. All of them have some issues that impair
>> the usability, from minor to greater:
>> 1) The options are added, removed and edited directly in the table
>> (example: "Session properties" > "Exclude from proxy"). The main problems
>> are:
>> - to remove an option you have to delete the contents of the cell;
>> - (a special annoying one) when editing the options if the cell doesn't
>> loose the focus and you close the dialogue the option doesn't get updated;
>> - there's no way to temporarily disable an option (not related to how
>> the management is done, but it's worth remarking it, as most of the
>> multiple related options, if not all, should provide a way to
>> enable/disable them);
>> - it may happen that the last row is not always shown immediately to
>> allow the addition of a new entry;
>> 2) The options are added, edited and removed with buttons, the fields of
>> those options are shown beneath the table listing the options (example:
>> "Options" > "Applications"). There are minor problems related to how the
>> buttons work and the fields being always editable.
>> - If by mistake you press the wrong button (pressing "new" again) it
>> will result in a lose of the additions;
>> - the fields are not updated if the keyboard is used (not related to
>> the management, but it's worth pointing, as this is a usability detail that
>> should be taken in consideration);
>> 3) The options are managed in a text area, this is, by far, the least
>> usable (example: "Options" > "Connections" > "Skip IP addresses (...)" text
>> area). There's no need to say too much about this way (it, almost, speaks
>> for itself), the user has to manually select the correct option to remove
>> it, which can be hard to pinpoint if you have a lot of those and there's no
>> way to disable an entry.
>> Not all the issues are described, but, more or less, the most relevant to
>> the ways of management, are.
>> The changes are an attempt to normalise how the management of multiple
>> related options is done throughout ZAP, so, hopefully, the user doesn't
>> have to jump from a way of doing it to another one completely different. It
>> should also allow the user to specify some details of those options, in the
>> case of the "Exclude from proxy", there should be an easy way to specify an
>> URL in plain text without the need to manually "quote" the "regular
>> expression", more over it allows to introduce other conditions not
>> restricted to a specific component of the message like the URL (may be
>> useful if the user wants to exclude files that are greater than a specific
>> size (determined through the "Content-Length" header field)).
>> Some of the other details regarding the usability of all the options:
>> - When an option is disabled, other options that depend on the disabled
>> option shouldn't be reset. If the user only wanted to disable temporarily
>> the option, he won't need to fill all the fields again (example: "Options"
>> > "Connections" > "Use an outgoing proxy server" if it is unchecked the
>> "Address", "Port" and "Skip IP addresses (...)" are reset);
>> - Addition of a button to reset the options to default values.
>> - The components should resize correctly when the dialogue is resized
>> (example: "Options" > "Connections" > "Skip IP addresses (...)" the text
>> area doesn't resize as most as it should).
>> I also want to allow the user to maximise the "Options" dialogue.
>> I was going to commit the changes (when ready) without asking about the
>> changes to the develop group, as there are much more advantages to what is
>> being done now that it seems to me that it's a natural change and that it
>> inevitably would happen (there are some issue(s) about the usability of
>> some options).
>> But as this subject as been brought here, I've attached a working example
>> on what the management will look like (if everyone agrees with it). If
>> anyone wants to see it and give some feedback, it would be greatly
>> appreciated.
>> Best regards.
>> On Wednesday, September 26, 2012 6:31:29 PM UTC+1, prasad wrote:
>>> Would there be any objection to changing the look and feel of the
>>> authentication options panel? The current one uses AbstractTable and model
>>> is not very flexible from what I could deduce. I would like to make the
>>> table more dynamic enabling users to add and delete authentication options
>>> quickly and easily. I have some ideas but want to get the pulse of the
>>> group.
>>> Any advice would be appreciated.
>>> [ ~ Prasad | @prasadshenoy ~]
>>> On Sat, Sep 22, 2012 at 4:07 AM, psiinon <psi...@gmail.com> wrote:
>>>> I've assigned the issue to you - go for it!
>>>> On Friday, 21 September 2012 18:05:48 UTC+1, prasad wrote:
>>>>> I would like to work on the password masking issue item.
>>>>> [ ~ Prasad | @prasadshenoy ~]
>>>>> On Fri, Sep 21, 2012 at 12:03 PM, psiinon <psi...@gmail.com> wrote:
>>>>>> On Friday, 21 September 2012 16:23:12 UTC+1, prasad wrote:
>>>>>>> Is the weak NTLM v* authentication support in ZAP due to the fact
>>>>>>> that it is built on Paros? I have always had a problem with the missing or
>>>>>>> lacking support for NTLM authentication in Paros. Is this a existing
>>>>>>> feature request? or can be added?
>>>>>>> Also, I have submitted a feature request to mask the passwords on
>>>>>>> the Authentication settings page.
I think that looking really good :) The buttons are much clearer and easier to use than the current 'in line' table editing. I think we should change all editable lists to work this way - maybe implement a generic control to do this that we can reuse? ;)
Very minor point - in the 'Confirm remove' dialog the buttons are labelled 'Yes' and 'No'. I think the current advice is to avoid these sort of labels as they can confuse users. Instead use labels that people can quickly understand without having to (mis) read the question, eg 'Delete' and 'Cancel'. Obviously its an easy fix!
On Friday, 28 September 2012 08:57:20 UTC+1, psiinon wrote:
> Awesome!
> This has been long overdue, but also a significant undertaking that I've > not been able to face looking at ;)
> I'll have a play with your changes as soon as I get a chance.
> Many thanks,
> Simon
> On Friday, 28 September 2012 01:14:52 UTC+1, thc202 wrote:
>> Hi.
>> If I am understanding you correctly, regarding the table model, you only >> need to implement the methods to add and remove the *HostAuthentication*(s) >> in the class *OptionsAuthenticationTableModel*.
>> Curiously, I'm about to finish some changes on how multiple related >> options are managed (which includes the management of the host >> authentication) and other details regarding the usability of all the >> options. >> Currently there are several ways, which can be grouped in 3 categories, >> on how those options are managed. All of them have some issues that impair >> the usability, from minor to greater: >> 1) The options are added, removed and edited directly in the table >> (example: "Session properties" > "Exclude from proxy"). The main problems >> are: >> - to remove an option you have to delete the contents of the cell; >> - (a special annoying one) when editing the options if the cell doesn't >> loose the focus and you close the dialogue the option doesn't get updated; >> - there's no way to temporarily disable an option (not related to how >> the management is done, but it's worth remarking it, as most of the >> multiple related options, if not all, should provide a way to >> enable/disable them); >> - it may happen that the last row is not always shown immediately to >> allow the addition of a new entry; >> 2) The options are added, edited and removed with buttons, the fields of >> those options are shown beneath the table listing the options (example: >> "Options" > "Applications"). There are minor problems related to how the >> buttons work and the fields being always editable. >> - If by mistake you press the wrong button (pressing "new" again) it >> will result in a lose of the additions; >> - the fields are not updated if the keyboard is used (not related to >> the management, but it's worth pointing, as this is a usability detail that >> should be taken in consideration); >> 3) The options are managed in a text area, this is, by far, the least >> usable (example: "Options" > "Connections" > "Skip IP addresses (...)" text >> area). There's no need to say too much about this way (it, almost, speaks >> for itself), the user has to manually select the correct option to remove >> it, which can be hard to pinpoint if you have a lot of those and there's no >> way to disable an entry.
>> Not all the issues are described, but, more or less, the most relevant to >> the ways of management, are.
>> The changes are an attempt to normalise how the management of multiple >> related options is done throughout ZAP, so, hopefully, the user doesn't >> have to jump from a way of doing it to another one completely different. It >> should also allow the user to specify some details of those options, in the >> case of the "Exclude from proxy", there should be an easy way to specify an >> URL in plain text without the need to manually "quote" the "regular >> expression", more over it allows to introduce other conditions not >> restricted to a specific component of the message like the URL (may be >> useful if the user wants to exclude files that are greater than a specific >> size (determined through the "Content-Length" header field)).
>> Some of the other details regarding the usability of all the options: >> - When an option is disabled, other options that depend on the disabled >> option shouldn't be reset. If the user only wanted to disable temporarily >> the option, he won't need to fill all the fields again (example: "Options" >> > "Connections" > "Use an outgoing proxy server" if it is unchecked the >> "Address", "Port" and "Skip IP addresses (...)" are reset); >> - Addition of a button to reset the options to default values. >> - The components should resize correctly when the dialogue is resized >> (example: "Options" > "Connections" > "Skip IP addresses (...)" the text >> area doesn't resize as most as it should).
>> I also want to allow the user to maximise the "Options" dialogue.
>> I was going to commit the changes (when ready) without asking about the >> changes to the develop group, as there are much more advantages to what is >> being done now that it seems to me that it's a natural change and that it >> inevitably would happen (there are some issue(s) about the usability of >> some options).
>> But as this subject as been brought here, I've attached a working example >> on what the management will look like (if everyone agrees with it). If >> anyone wants to see it and give some feedback, it would be greatly >> appreciated.
>> Best regards.
>> On Wednesday, September 26, 2012 6:31:29 PM UTC+1, prasad wrote:
>>> Would there be any objection to changing the look and feel of the >>> authentication options panel? The current one uses AbstractTable and model >>> is not very flexible from what I could deduce. I would like to make the >>> table more dynamic enabling users to add and delete authentication options >>> quickly and easily. I have some ideas but want to get the pulse of the >>> group.
>>> Any advice would be appreciated.
>>> [ ~ Prasad | @prasadshenoy ~]
>>> On Sat, Sep 22, 2012 at 4:07 AM, psiinon <psi...@gmail.com> wrote:
>>>> I've assigned the issue to you - go for it!
>>>> On Friday, 21 September 2012 18:05:48 UTC+1, prasad wrote:
>>>>> I would like to work on the password masking issue item.
>>>>> [ ~ Prasad | @prasadshenoy ~]
>>>>> On Fri, Sep 21, 2012 at 12:03 PM, psiinon <psi...@gmail.com> wrote:
>>>>>> On Friday, 21 September 2012 16:23:12 UTC+1, prasad wrote:
>>>>>>> Is the weak NTLM v* authentication support in ZAP due to the fact >>>>>>> that it is built on Paros? I have always had a problem with the missing or >>>>>>> lacking support for NTLM authentication in Paros. Is this a existing >>>>>>> feature request? or can be added?
>>>>>>> Also, I have submitted a feature request to mask the passwords on >>>>>>> the Authentication settings page.
On Thursday, 4 October 2012 16:49:34 UTC+1, psiinon wrote:
> I think that looking really good :) > The buttons are much clearer and easier to use than the current 'in line' > table editing. > I think we should change all editable lists to work this way - maybe > implement a generic control to do this that we can reuse? ;)
> Very minor point - in the 'Confirm remove' dialog the buttons are labelled > 'Yes' and 'No'. > I think the current advice is to avoid these sort of labels as they can > confuse users. > Instead use labels that people can quickly understand without having to > (mis) read the question, eg 'Delete' and 'Cancel'. > Obviously its an easy fix!
> Cheers,
> Simon
> On Friday, 28 September 2012 08:57:20 UTC+1, psiinon wrote:
>> Awesome!
>> This has been long overdue, but also a significant undertaking that I've >> not been able to face looking at ;)
>> I'll have a play with your changes as soon as I get a chance.
>> Many thanks,
>> Simon
>> On Friday, 28 September 2012 01:14:52 UTC+1, thc202 wrote:
>>> Hi.
>>> If I am understanding you correctly, regarding the table model, you only >>> need to implement the methods to add and remove the *HostAuthentication*(s) >>> in the class *OptionsAuthenticationTableModel*.
>>> Curiously, I'm about to finish some changes on how multiple related >>> options are managed (which includes the management of the host >>> authentication) and other details regarding the usability of all the >>> options. >>> Currently there are several ways, which can be grouped in 3 categories, >>> on how those options are managed. All of them have some issues that impair >>> the usability, from minor to greater: >>> 1) The options are added, removed and edited directly in the table >>> (example: "Session properties" > "Exclude from proxy"). The main problems >>> are: >>> - to remove an option you have to delete the contents of the cell; >>> - (a special annoying one) when editing the options if the cell >>> doesn't loose the focus and you close the dialogue the option doesn't get >>> updated; >>> - there's no way to temporarily disable an option (not related to how >>> the management is done, but it's worth remarking it, as most of the >>> multiple related options, if not all, should provide a way to >>> enable/disable them); >>> - it may happen that the last row is not always shown immediately to >>> allow the addition of a new entry; >>> 2) The options are added, edited and removed with buttons, the fields >>> of those options are shown beneath the table listing the options (example: >>> "Options" > "Applications"). There are minor problems related to how the >>> buttons work and the fields being always editable. >>> - If by mistake you press the wrong button (pressing "new" again) it >>> will result in a lose of the additions; >>> - the fields are not updated if the keyboard is used (not related to >>> the management, but it's worth pointing, as this is a usability detail that >>> should be taken in consideration); >>> 3) The options are managed in a text area, this is, by far, the least >>> usable (example: "Options" > "Connections" > "Skip IP addresses (...)" text >>> area). There's no need to say too much about this way (it, almost, speaks >>> for itself), the user has to manually select the correct option to remove >>> it, which can be hard to pinpoint if you have a lot of those and there's no >>> way to disable an entry.
>>> Not all the issues are described, but, more or less, the most relevant >>> to the ways of management, are.
>>> The changes are an attempt to normalise how the management of multiple >>> related options is done throughout ZAP, so, hopefully, the user doesn't >>> have to jump from a way of doing it to another one completely different. It >>> should also allow the user to specify some details of those options, in the >>> case of the "Exclude from proxy", there should be an easy way to specify an >>> URL in plain text without the need to manually "quote" the "regular >>> expression", more over it allows to introduce other conditions not >>> restricted to a specific component of the message like the URL (may be >>> useful if the user wants to exclude files that are greater than a specific >>> size (determined through the "Content-Length" header field)).
>>> Some of the other details regarding the usability of all the options: >>> - When an option is disabled, other options that depend on the disabled >>> option shouldn't be reset. If the user only wanted to disable temporarily >>> the option, he won't need to fill all the fields again (example: "Options" >>> > "Connections" > "Use an outgoing proxy server" if it is unchecked the >>> "Address", "Port" and "Skip IP addresses (...)" are reset); >>> - Addition of a button to reset the options to default values. >>> - The components should resize correctly when the dialogue is resized >>> (example: "Options" > "Connections" > "Skip IP addresses (...)" the text >>> area doesn't resize as most as it should).
>>> I also want to allow the user to maximise the "Options" dialogue.
>>> I was going to commit the changes (when ready) without asking about the >>> changes to the develop group, as there are much more advantages to what is >>> being done now that it seems to me that it's a natural change and that it >>> inevitably would happen (there are some issue(s) about the usability of >>> some options).
>>> But as this subject as been brought here, I've attached a working >>> example on what the management will look like (if everyone agrees with it). >>> If anyone wants to see it and give some feedback, it would be greatly >>> appreciated.
>>> Best regards.
>>> On Wednesday, September 26, 2012 6:31:29 PM UTC+1, prasad wrote:
>>>> Would there be any objection to changing the look and feel of the >>>> authentication options panel? The current one uses AbstractTable and model >>>> is not very flexible from what I could deduce. I would like to make the >>>> table more dynamic enabling users to add and delete authentication options >>>> quickly and easily. I have some ideas but want to get the pulse of the >>>> group.
>>>> Any advice would be appreciated.
>>>> [ ~ Prasad | @prasadshenoy ~]
>>>> On Sat, Sep 22, 2012 at 4:07 AM, psiinon <psi...@gmail.com> wrote:
>>>>> I've assigned the issue to you - go for it!
>>>>> On Friday, 21 September 2012 18:05:48 UTC+1, prasad wrote:
>>>>>> I would like to work on the password masking issue item.
>>>>>> [ ~ Prasad | @prasadshenoy ~]
>>>>>> On Fri, Sep 21, 2012 at 12:03 PM, psiinon <psi...@gmail.com> wrote:
>>>>>>> Yes :) >>>>>>> I cant see an existing request for it, but feel free to add it<http://code.google.com/p/zaproxy/issues/entry> >>>>>>> ! >>>>>>> I must admit I dont do any assessments on apps that use NTLM, but it >>>>>>> would be really good for ZAP to support it properly. >>>>>>> That could be a useful project<http://code.google.com/p/zaproxy/wiki/Projects>?
>>>>>>> And good suggestion for the passwords :)
>>>>>>> Many thanks,
>>>>>>> Simon
>>>>>>> On Friday, 21 September 2012 16:23:12 UTC+1, prasad wrote:
>>>>>>>> Is the weak NTLM v* authentication support in ZAP due to the fact >>>>>>>> that it is built on Paros? I have always had a problem with the missing or >>>>>>>> lacking support for NTLM authentication in Paros. Is this a existing >>>>>>>> feature request? or can be added?
>>>>>>>> Also, I have submitted a feature request to mask the passwords on >>>>>>>> the Authentication settings page.
I apologize for not being able to contribute much in past few weeks. I was occupied with a few other things and expect to get back in routine ASAP. Please keep the Password Mask feature assigned to me as I continue I work on it :). At some point soon, I will take a look at the proposed changes by THC and am sure that will address majority of the UI issues we are discussing today.
Thank you,
Prasad N. Shenoy
On Nov 2, 2012, at 10:07 AM, psiinon <psii...@gmail.com> wrote:
> Hi THC - have you made any more progress with the options?
> Cheers,
> Simon
> On Thursday, 4 October 2012 16:49:34 UTC+1, psiinon wrote:
>> I think that looking really good :)
>> The buttons are much clearer and easier to use than the current 'in line' table editing.
>> I think we should change all editable lists to work this way - maybe implement a generic control to do this that we can reuse? ;)
>> Very minor point - in the 'Confirm remove' dialog the buttons are labelled 'Yes' and 'No'.
>> I think the current advice is to avoid these sort of labels as they can confuse users.
>> Instead use labels that people can quickly understand without having to (mis) read the question, eg 'Delete' and 'Cancel'.
>> Obviously its an easy fix!
>> Cheers,
>> Simon
>> On Friday, 28 September 2012 08:57:20 UTC+1, psiinon wrote:
>>> Awesome!
>>> This has been long overdue, but also a significant undertaking that I've not been able to face looking at ;)
>>> I'll have a play with your changes as soon as I get a chance.
>>> Many thanks,
>>> Simon
>>> On Friday, 28 September 2012 01:14:52 UTC+1, thc202 wrote:
>>>> Hi.
>>>> If I am understanding you correctly, regarding the table model, you only need to implement the methods to add and remove the HostAuthentication(s) in the class OptionsAuthenticationTableModel.
>>>> Curiously, I'm about to finish some changes on how multiple related options are managed (which includes the management of the host authentication) and other details regarding the usability of all the options.
>>>> Currently there are several ways, which can be grouped in 3 categories, on how those options are managed. All of them have some issues that impair the usability, from minor to greater:
>>>> 1) The options are added, removed and edited directly in the table (example: "Session properties" > "Exclude from proxy"). The main problems are: >>>> - to remove an option you have to delete the contents of the cell;
>>>> - (a special annoying one) when editing the options if the cell doesn't loose the focus and you close the dialogue the option doesn't get updated;
>>>> - there's no way to temporarily disable an option (not related to how the management is done, but it's worth remarking it, as most of the multiple related options, if not all, should provide a way to enable/disable them);
>>>> - it may happen that the last row is not always shown immediately to allow the addition of a new entry;
>>>> 2) The options are added, edited and removed with buttons, the fields of those options are shown beneath the table listing the options (example: "Options" > "Applications"). There are minor problems related to how the buttons work and the fields being always editable.
>>>> - If by mistake you press the wrong button (pressing "new" again) it will result in a lose of the additions;
>>>> - the fields are not updated if the keyboard is used (not related to the management, but it's worth pointing, as this is a usability detail that should be taken in consideration);
>>>> 3) The options are managed in a text area, this is, by far, the least usable (example: "Options" > "Connections" > "Skip IP addresses (...)" text area). There's no need to say too much about this way (it, almost, speaks for itself), the user has to manually select the correct option to remove it, which can be hard to pinpoint if you have a lot of those and there's no way to disable an entry.
>>>> Not all the issues are described, but, more or less, the most relevant to the ways of management, are.
>>>> The changes are an attempt to normalise how the management of multiple related options is done throughout ZAP, so, hopefully, the user doesn't have to jump from a way of doing it to another one completely different. It should also allow the user to specify some details of those options, in the case of the "Exclude from proxy", there should be an easy way to specify an URL in plain text without the need to manually "quote" the "regular expression", more over it allows to introduce other conditions not restricted to a specific component of the message like the URL (may be useful if the user wants to exclude files that are greater than a specific size (determined through the "Content-Length" header field)).
>>>> Some of the other details regarding the usability of all the options:
>>>> - When an option is disabled, other options that depend on the disabled option shouldn't be reset. If the user only wanted to disable temporarily the option, he won't need to fill all the fields again (example: "Options" > "Connections" > "Use an outgoing proxy server" if it is unchecked the "Address", "Port" and "Skip IP addresses (...)" are reset);
>>>> - Addition of a button to reset the options to default values.
>>>> - The components should resize correctly when the dialogue is resized (example: "Options" > "Connections" > "Skip IP addresses (...)" the text area doesn't resize as most as it should).
>>>> I also want to allow the user to maximise the "Options" dialogue.
>>>> I was going to commit the changes (when ready) without asking about the changes to the develop group, as there are much more advantages to what is being done now that it seems to me that it's a natural change and that it inevitably would happen (there are some issue(s) about the usability of some options).
>>>> But as this subject as been brought here, I've attached a working example on what the management will look like (if everyone agrees with it). If anyone wants to see it and give some feedback, it would be greatly appreciated.
>>>> Best regards.
>>>> On Wednesday, September 26, 2012 6:31:29 PM UTC+1, prasad wrote:
>>>>> Would there be any objection to changing the look and feel of the authentication options panel? The current one uses AbstractTable and model is not very flexible from what I could deduce. I would like to make the table more dynamic enabling users to add and delete authentication options quickly and easily. I have some ideas but want to get the pulse of the group.
>>>>> Any advice would be appreciated.
>>>>> [ ~ Prasad | @prasadshenoy ~]
>>>>> On Sat, Sep 22, 2012 at 4:07 AM, psiinon <psi...@gmail.com> wrote:
>>>>>> I've assigned the issue to you - go for it!
>>>>>> On Friday, 21 September 2012 18:05:48 UTC+1, prasad wrote:
>>>>>>> I would like to work on the password masking issue item.
>>>>>>> [ ~ Prasad | @prasadshenoy ~]
>>>>>>> On Fri, Sep 21, 2012 at 12:03 PM, psiinon <psi...@gmail.com> wrote:
>>>>>>>> Yes :)
>>>>>>>> I cant see an existing request for it, but feel free to add it!
>>>>>>>> I must admit I dont do any assessments on apps that use NTLM, but it would be really good for ZAP to support it properly.
>>>>>>>> That could be a useful project?
>>>>>>>> And good suggestion for the passwords :)
>>>>>>>> Many thanks,
>>>>>>>> Simon
>>>>>>>> On Friday, 21 September 2012 16:23:12 UTC+1, prasad wrote:
>>>>>>>>> Is the weak NTLM v* authentication support in ZAP due to the fact that it is built on Paros? I have always had a problem with the missing or lacking support for NTLM authentication in Paros. Is this a existing feature request? or can be added?
>>>>>>>>> Also, I have submitted a feature request to mask the passwords on the Authentication settings page.
It was put (a little) aside some time ago but should be ready for the next weekly release (the needed changes in the help pages probably not).
Regarding the previous message, sorry for not answering before.
Thanks for the feedback! It's really appreciated.
Yes, the idea is to change every listing/management of multiple related options to use the same component, so the UI and management of those options is consistent throughout ZAP.
OK, thanks for the advice, I'll change the labels.
On Friday, 2 November 2012 14:07:22 UTC, psiinon wrote:
> Hi THC - have you made any more progress with the options?
> Cheers,
> Simon
> On Thursday, 4 October 2012 16:49:34 UTC+1, psiinon wrote:
>> I think that looking really good :) >> The buttons are much clearer and easier to use than the current 'in line' >> table editing. >> I think we should change all editable lists to work this way - maybe >> implement a generic control to do this that we can reuse? ;)
>> Very minor point - in the 'Confirm remove' dialog the buttons are >> labelled 'Yes' and 'No'. >> I think the current advice is to avoid these sort of labels as they can >> confuse users. >> Instead use labels that people can quickly understand without having to >> (mis) read the question, eg 'Delete' and 'Cancel'. >> Obviously its an easy fix!
>> Cheers,
>> Simon
>> On Friday, 28 September 2012 08:57:20 UTC+1, psiinon wrote:
>>> Awesome!
>>> This has been long overdue, but also a significant undertaking that I've >>> not been able to face looking at ;)
>>> I'll have a play with your changes as soon as I get a chance.
>>> Many thanks,
>>> Simon
>>> On Friday, 28 September 2012 01:14:52 UTC+1, thc202 wrote:
>>>> Hi.
>>>> If I am understanding you correctly, regarding the table model, you >>>> only need to implement the methods to add and remove the * >>>> HostAuthentication*(s) in the class *OptionsAuthenticationTableModel*.
>>>> Curiously, I'm about to finish some changes on how multiple related >>>> options are managed (which includes the management of the host >>>> authentication) and other details regarding the usability of all the >>>> options. >>>> Currently there are several ways, which can be grouped in 3 categories, >>>> on how those options are managed. All of them have some issues that impair >>>> the usability, from minor to greater: >>>> 1) The options are added, removed and edited directly in the table >>>> (example: "Session properties" > "Exclude from proxy"). The main problems >>>> are: >>>> - to remove an option you have to delete the contents of the cell; >>>> - (a special annoying one) when editing the options if the cell >>>> doesn't loose the focus and you close the dialogue the option doesn't get >>>> updated; >>>> - there's no way to temporarily disable an option (not related to how >>>> the management is done, but it's worth remarking it, as most of the >>>> multiple related options, if not all, should provide a way to >>>> enable/disable them); >>>> - it may happen that the last row is not always shown immediately to >>>> allow the addition of a new entry; >>>> 2) The options are added, edited and removed with buttons, the fields >>>> of those options are shown beneath the table listing the options (example: >>>> "Options" > "Applications"). There are minor problems related to how the >>>> buttons work and the fields being always editable. >>>> - If by mistake you press the wrong button (pressing "new" again) it >>>> will result in a lose of the additions; >>>> - the fields are not updated if the keyboard is used (not related to >>>> the management, but it's worth pointing, as this is a usability detail that >>>> should be taken in consideration); >>>> 3) The options are managed in a text area, this is, by far, the least >>>> usable (example: "Options" > "Connections" > "Skip IP addresses (...)" text >>>> area). There's no need to say too much about this way (it, almost, speaks >>>> for itself), the user has to manually select the correct option to remove >>>> it, which can be hard to pinpoint if you have a lot of those and there's no >>>> way to disable an entry.
>>>> Not all the issues are described, but, more or less, the most relevant >>>> to the ways of management, are.
>>>> The changes are an attempt to normalise how the management of multiple >>>> related options is done throughout ZAP, so, hopefully, the user doesn't >>>> have to jump from a way of doing it to another one completely different. It >>>> should also allow the user to specify some details of those options, in the >>>> case of the "Exclude from proxy", there should be an easy way to specify an >>>> URL in plain text without the need to manually "quote" the "regular >>>> expression", more over it allows to introduce other conditions not >>>> restricted to a specific component of the message like the URL (may be >>>> useful if the user wants to exclude files that are greater than a specific >>>> size (determined through the "Content-Length" header field)).
>>>> Some of the other details regarding the usability of all the options: >>>> - When an option is disabled, other options that depend on the >>>> disabled option shouldn't be reset. If the user only wanted to disable >>>> temporarily the option, he won't need to fill all the fields again >>>> (example: "Options" > "Connections" > "Use an outgoing proxy server" if it >>>> is unchecked the "Address", "Port" and "Skip IP addresses (...)" are reset); >>>> - Addition of a button to reset the options to default values. >>>> - The components should resize correctly when the dialogue is resized >>>> (example: "Options" > "Connections" > "Skip IP addresses (...)" the text >>>> area doesn't resize as most as it should).
>>>> I also want to allow the user to maximise the "Options" dialogue.
>>>> I was going to commit the changes (when ready) without asking about the >>>> changes to the develop group, as there are much more advantages to what is >>>> being done now that it seems to me that it's a natural change and that it >>>> inevitably would happen (there are some issue(s) about the usability of >>>> some options).
>>>> But as this subject as been brought here, I've attached a working >>>> example on what the management will look like (if everyone agrees with it). >>>> If anyone wants to see it and give some feedback, it would be greatly >>>> appreciated.
>>>> Best regards.
>>>> On Wednesday, September 26, 2012 6:31:29 PM UTC+1, prasad wrote:
>>>>> Would there be any objection to changing the look and feel of the >>>>> authentication options panel? The current one uses AbstractTable and model >>>>> is not very flexible from what I could deduce. I would like to make the >>>>> table more dynamic enabling users to add and delete authentication options >>>>> quickly and easily. I have some ideas but want to get the pulse of the >>>>> group.
>>>>> Any advice would be appreciated.
>>>>> [ ~ Prasad | @prasadshenoy ~]
>>>>> On Sat, Sep 22, 2012 at 4:07 AM, psiinon <psi...@gmail.com> wrote:
>>>>>> I've assigned the issue to you - go for it!
>>>>>> On Friday, 21 September 2012 18:05:48 UTC+1, prasad wrote:
>>>>>>> I would like to work on the password masking issue item.
>>>>>>> [ ~ Prasad | @prasadshenoy ~]
>>>>>>> On Fri, Sep 21, 2012 at 12:03 PM, psiinon <psi...@gmail.com> wrote:
>>>>>>>> Yes :) >>>>>>>> I cant see an existing request for it, but feel free to add it<http://code.google.com/p/zaproxy/issues/entry> >>>>>>>> ! >>>>>>>> I must admit I dont do any assessments on apps that use NTLM, but >>>>>>>> it would be really good for ZAP to support it properly. >>>>>>>> That could be a useful project<http://code.google.com/p/zaproxy/wiki/Projects>?
>>>>>>>> And good suggestion for the passwords :)
>>>>>>>> Many thanks,
>>>>>>>> Simon
>>>>>>>> On Friday, 21 September 2012 16:23:12 UTC+1, prasad wrote:
>>>>>>>>> Is the weak NTLM v* authentication support in ZAP due to the fact >>>>>>>>> that it is built on Paros? I have always had a problem with the missing or >>>>>>>>> lacking support for NTLM authentication in Paros. Is this a existing >>>>>>>>> feature request? or can be added?
>>>>>>>>> Also, I have submitted a feature request to mask the passwords on >>>>>>>>> the Authentication settings page.
> If I am understanding you correctly, regarding the table model, you only need to implement the methods to add and remove the HostAuthentication(s) in the class OptionsAuthenticationTableModel.
> Curiously, I'm about to finish some changes on how multiple related options are managed (which includes the management of the host authentication) and other details regarding the usability of all the options.
> Currently there are several ways, which can be grouped in 3 categories, on how those options are managed. All of them have some issues that impair the usability, from minor to greater:
> 1) The options are added, removed and edited directly in the table (example: "Session properties" > "Exclude from proxy"). The main problems are: > - to remove an option you have to delete the contents of the cell;
> - (a special annoying one) when editing the options if the cell doesn't loose the focus and you close the dialogue the option doesn't get updated;
> - there's no way to temporarily disable an option (not related to how the management is done, but it's worth remarking it, as most of the multiple related options, if not all, should provide a way to enable/disable them);
> - it may happen that the last row is not always shown immediately to allow the addition of a new entry;
> 2) The options are added, edited and removed with buttons, the fields of those options are shown beneath the table listing the options (example: "Options" > "Applications"). There are minor problems related to how the buttons work and the fields being always editable.
> - If by mistake you press the wrong button (pressing "new" again) it will result in a lose of the additions;
> - the fields are not updated if the keyboard is used (not related to the management, but it's worth pointing, as this is a usability detail that should be taken in consideration);
> 3) The options are managed in a text area, this is, by far, the least usable (example: "Options" > "Connections" > "Skip IP addresses (...)" text area). There's no need to say too much about this way (it, almost, speaks for itself), the user has to manually select the correct option to remove it, which can be hard to pinpoint if you have a lot of those and there's no way to disable an entry.
> Not all the issues are described, but, more or less, the most relevant to the ways of management, are.
> The changes are an attempt to normalise how the management of multiple related options is done throughout ZAP, so, hopefully, the user doesn't have to jump from a way of doing it to another one completely different. It should also allow the user to specify some details of those options, in the case of the "Exclude from proxy", there should be an easy way to specify an URL in plain text without the need to manually "quote" the "regular expression", more over it allows to introduce other conditions not restricted to a specific component of the message like the URL (may be useful if the user wants to exclude files that are greater than a specific size (determined through the "Content-Length" header field)).
> Some of the other details regarding the usability of all the options:
> - When an option is disabled, other options that depend on the disabled option shouldn't be reset. If the user only wanted to disable temporarily the option, he won't need to fill all the fields again (example: "Options" > "Connections" > "Use an outgoing proxy server" if it is unchecked the "Address", "Port" and "Skip IP addresses (...)" are reset);
> - Addition of a button to reset the options to default values.
> - The components should resize correctly when the dialogue is resized (example: "Options" > "Connections" > "Skip IP addresses (...)" the text area doesn't resize as most as it should).
> I also want to allow the user to maximise the "Options" dialogue.
> I was going to commit the changes (when ready) without asking about the changes to the develop group, as there are much more advantages to what is being done now that it seems to me that it's a natural change and that it inevitably would happen (there are some issue(s) about the usability of some options).
> But as this subject as been brought here, I've attached a working example on what the management will look like (if everyone agrees with it). If anyone wants to see it and give some feedback, it would be greatly appreciated.
> Best regards.
> On Wednesday, September 26, 2012 6:31:29 PM UTC+1, prasad wrote:
> Would there be any objection to changing the look and feel of the authentication options panel? The current one uses AbstractTable and model is not very flexible from what I could deduce. I would like to make the table more dynamic enabling users to add and delete authentication options quickly and easily. I have some ideas but want to get the pulse of the group.
> Any advice would be appreciated.
> [ ~ Prasad | @prasadshenoy ~]
> On Sat, Sep 22, 2012 at 4:07 AM, psiinon <psi...@gmail.com> wrote:
> I've assigned the issue to you - go for it!
> On Friday, 21 September 2012 18:05:48 UTC+1, prasad wrote:
> I would like to work on the password masking issue item.
> [ ~ Prasad | @prasadshenoy ~]
> On Fri, Sep 21, 2012 at 12:03 PM, psiinon <psi...@gmail.com> wrote:
> Yes :)
> I cant see an existing request for it, but feel free to add it!
> I must admit I dont do any assessments on apps that use NTLM, but it would be really good for ZAP to support it properly.
> That could be a useful project?
> And good suggestion for the passwords :)
> Many thanks,
> Simon
> On Friday, 21 September 2012 16:23:12 UTC+1, prasad wrote:
> Is the weak NTLM v* authentication support in ZAP due to the fact that it is built on Paros? I have always had a problem with the missing or lacking support for NTLM authentication in Paros. Is this a existing feature request? or can be added?
> Also, I have submitted a feature request to mask the passwords on the Authentication settings page.
There are some issues that are delaying the commit of the changes, as I wanted to have it already included in the previous weekly release, but you should be able to make the required changes to display the masked password without problems as the model (*OptionsAuthenticationTableModel*) and panel (*OptionsAuthenticationPanel*) will be the same, or it's also to be masked in the configuration file?
The password should also be masked in the dialogues to add and modify the host authentication?
On Thursday, 8 November 2012 04:35:29 UTC, prasad wrote:
> thc202,
> I agree. This looks really good and closer to what I had anticipated. What > is the plan now? I would like to work on password masking to begin with.
> Thanks > Prasad
> On Sep 27, 2012, at 8:14 PM, thc202 <thc...@gmail.com <javascript:>> > wrote:
> Hi.
> If I am understanding you correctly, regarding the table model, you only > need to implement the methods to add and remove the *HostAuthentication*(s) > in the class *OptionsAuthenticationTableModel*.
> Curiously, I'm about to finish some changes on how multiple related > options are managed (which includes the management of the host > authentication) and other details regarding the usability of all the > options. > Currently there are several ways, which can be grouped in 3 categories, on > how those options are managed. All of them have some issues that impair the > usability, from minor to greater: > 1) The options are added, removed and edited directly in the table > (example: "Session properties" > "Exclude from proxy"). The main problems > are: > - to remove an option you have to delete the contents of the cell; > - (a special annoying one) when editing the options if the cell doesn't > loose the focus and you close the dialogue the option doesn't get updated; > - there's no way to temporarily disable an option (not related to how > the management is done, but it's worth remarking it, as most of the > multiple related options, if not all, should provide a way to > enable/disable them); > - it may happen that the last row is not always shown immediately to > allow the addition of a new entry; > 2) The options are added, edited and removed with buttons, the fields of > those options are shown beneath the table listing the options (example: > "Options" > "Applications"). There are minor problems related to how the > buttons work and the fields being always editable. > - If by mistake you press the wrong button (pressing "new" again) it > will result in a lose of the additions; > - the fields are not updated if the keyboard is used (not related to the > management, but it's worth pointing, as this is a usability detail that > should be taken in consideration); > 3) The options are managed in a text area, this is, by far, the least > usable (example: "Options" > "Connections" > "Skip IP addresses (...)" text > area). There's no need to say too much about this way (it, almost, speaks > for itself), the user has to manually select the correct option to remove > it, which can be hard to pinpoint if you have a lot of those and there's no > way to disable an entry.
> Not all the issues are described, but, more or less, the most relevant to > the ways of management, are.
> The changes are an attempt to normalise how the management of multiple > related options is done throughout ZAP, so, hopefully, the user doesn't > have to jump from a way of doing it to another one completely different. It > should also allow the user to specify some details of those options, in the > case of the "Exclude from proxy", there should be an easy way to specify an > URL in plain text without the need to manually "quote" the "regular > expression", more over it allows to introduce other conditions not > restricted to a specific component of the message like the URL (may be > useful if the user wants to exclude files that are greater than a specific > size (determined through the "Content-Length" header field)).
> Some of the other details regarding the usability of all the options: > - When an option is disabled, other options that depend on the disabled > option shouldn't be reset. If the user only wanted to disable temporarily > the option, he won't need to fill all the fields again (example: "Options" > > "Connections" > "Use an outgoing proxy server" if it is unchecked the > "Address", "Port" and "Skip IP addresses (...)" are reset); > - Addition of a button to reset the options to default values. > - The components should resize correctly when the dialogue is resized > (example: "Options" > "Connections" > "Skip IP addresses (...)" the text > area doesn't resize as most as it should).
> I also want to allow the user to maximise the "Options" dialogue.
> I was going to commit the changes (when ready) without asking about the > changes to the develop group, as there are much more advantages to what is > being done now that it seems to me that it's a natural change and that it > inevitably would happen (there are some issue(s) about the usability of > some options).
> But as this subject as been brought here, I've attached a working example > on what the management will look like (if everyone agrees with it). If > anyone wants to see it and give some feedback, it would be greatly > appreciated.
> Best regards.
> On Wednesday, September 26, 2012 6:31:29 PM UTC+1, prasad wrote:
>> Would there be any objection to changing the look and feel of the >> authentication options panel? The current one uses AbstractTable and model >> is not very flexible from what I could deduce. I would like to make the >> table more dynamic enabling users to add and delete authentication options >> quickly and easily. I have some ideas but want to get the pulse of the >> group.
>> Any advice would be appreciated.
>> [ ~ Prasad | @prasadshenoy ~]
>> On Sat, Sep 22, 2012 at 4:07 AM, psiinon <psi...@gmail.com> wrote:
>>> I've assigned the issue to you - go for it!
>>> On Friday, 21 September 2012 18:05:48 UTC+1, prasad wrote:
>>>> I would like to work on the password masking issue item.
>>>> [ ~ Prasad | @prasadshenoy ~]
>>>> On Fri, Sep 21, 2012 at 12:03 PM, psiinon <psi...@gmail.com> wrote:
>>>>> On Friday, 21 September 2012 16:23:12 UTC+1, prasad wrote:
>>>>>> Is the weak NTLM v* authentication support in ZAP due to the fact >>>>>> that it is built on Paros? I have always had a problem with the missing or >>>>>> lacking support for NTLM authentication in Paros. Is this a existing >>>>>> feature request? or can be added?
>>>>>> Also, I have submitted a feature request to mask the passwords on the >>>>>> Authentication settings page.
This idea is to mask the passwords via dialogs. That would be on Authentication panel and other places where passwords are requested, in a consistent manner.
Are you sure I don't need to wait for your code to be committed? There won't be any Mask Password button in the current layout so how do I write a listener to mask/unmask etc? I might be missing something. If so, please help me understand.
Thank you,
Prasad N. Shenoy
On Nov 9, 2012, at 4:50 PM, thc202 <thc...@gmail.com> wrote:
> There are some issues that are delaying the commit of the changes, as I wanted to have it already included in the previous weekly release, but you should be able to make the required changes to display the masked password without problems as the model (OptionsAuthenticationTableModel) and panel (OptionsAuthenticationPanel) will be the same, or it's also to be masked in the configuration file?
> The password should also be masked in the dialogues to add and modify the host authentication?
> Best regards.
> On Thursday, 8 November 2012 04:35:29 UTC, prasad wrote:
>> thc202,
>> I agree. This looks really good and closer to what I had anticipated. What is the plan now? I would like to work on password masking to begin with.
>> Thanks
>> Prasad
>> On Sep 27, 2012, at 8:14 PM, thc202 <thc...@gmail.com> wrote:
>>> Hi.
>>> If I am understanding you correctly, regarding the table model, you only need to implement the methods to add and remove the HostAuthentication(s) in the class OptionsAuthenticationTableModel.
>>> Curiously, I'm about to finish some changes on how multiple related options are managed (which includes the management of the host authentication) and other details regarding the usability of all the options.
>>> Currently there are several ways, which can be grouped in 3 categories, on how those options are managed. All of them have some issues that impair the usability, from minor to greater:
>>> 1) The options are added, removed and edited directly in the table (example: "Session properties" > "Exclude from proxy"). The main problems are: >>> - to remove an option you have to delete the contents of the cell;
>>> - (a special annoying one) when editing the options if the cell doesn't loose the focus and you close the dialogue the option doesn't get updated;
>>> - there's no way to temporarily disable an option (not related to how the management is done, but it's worth remarking it, as most of the multiple related options, if not all, should provide a way to enable/disable them);
>>> - it may happen that the last row is not always shown immediately to allow the addition of a new entry;
>>> 2) The options are added, edited and removed with buttons, the fields of those options are shown beneath the table listing the options (example: "Options" > "Applications"). There are minor problems related to how the buttons work and the fields being always editable.
>>> - If by mistake you press the wrong button (pressing "new" again) it will result in a lose of the additions;
>>> - the fields are not updated if the keyboard is used (not related to the management, but it's worth pointing, as this is a usability detail that should be taken in consideration);
>>> 3) The options are managed in a text area, this is, by far, the least usable (example: "Options" > "Connections" > "Skip IP addresses (...)" text area). There's no need to say too much about this way (it, almost, speaks for itself), the user has to manually select the correct option to remove it, which can be hard to pinpoint if you have a lot of those and there's no way to disable an entry.
>>> Not all the issues are described, but, more or less, the most relevant to the ways of management, are.
>>> The changes are an attempt to normalise how the management of multiple related options is done throughout ZAP, so, hopefully, the user doesn't have to jump from a way of doing it to another one completely different. It should also allow the user to specify some details of those options, in the case of the "Exclude from proxy", there should be an easy way to specify an URL in plain text without the need to manually "quote" the "regular expression", more over it allows to introduce other conditions not restricted to a specific component of the message like the URL (may be useful if the user wants to exclude files that are greater than a specific size (determined through the "Content-Length" header field)).
>>> Some of the other details regarding the usability of all the options:
>>> - When an option is disabled, other options that depend on the disabled option shouldn't be reset. If the user only wanted to disable temporarily the option, he won't need to fill all the fields again (example: "Options" > "Connections" > "Use an outgoing proxy server" if it is unchecked the "Address", "Port" and "Skip IP addresses (...)" are reset);
>>> - Addition of a button to reset the options to default values.
>>> - The components should resize correctly when the dialogue is resized (example: "Options" > "Connections" > "Skip IP addresses (...)" the text area doesn't resize as most as it should).
>>> I also want to allow the user to maximise the "Options" dialogue.
>>> I was going to commit the changes (when ready) without asking about the changes to the develop group, as there are much more advantages to what is being done now that it seems to me that it's a natural change and that it inevitably would happen (there are some issue(s) about the usability of some options).
>>> But as this subject as been brought here, I've attached a working example on what the management will look like (if everyone agrees with it). If anyone wants to see it and give some feedback, it would be greatly appreciated.
>>> Best regards.
>>> On Wednesday, September 26, 2012 6:31:29 PM UTC+1, prasad wrote:
>>>> Would there be any objection to changing the look and feel of the authentication options panel? The current one uses AbstractTable and model is not very flexible from what I could deduce. I would like to make the table more dynamic enabling users to add and delete authentication options quickly and easily. I have some ideas but want to get the pulse of the group.
>>>> Any advice would be appreciated.
>>>> [ ~ Prasad | @prasadshenoy ~]
>>>> On Sat, Sep 22, 2012 at 4:07 AM, psiinon <psi...@gmail.com> wrote:
>>>>> I've assigned the issue to you - go for it!
>>>>> On Friday, 21 September 2012 18:05:48 UTC+1, prasad wrote:
>>>>>> I would like to work on the password masking issue item.
>>>>>> [ ~ Prasad | @prasadshenoy ~]
>>>>>> On Fri, Sep 21, 2012 at 12:03 PM, psiinon <psi...@gmail.com> wrote:
>>>>>>> Yes :)
>>>>>>> I cant see an existing request for it, but feel free to add it!
>>>>>>> I must admit I dont do any assessments on apps that use NTLM, but it would be really good for ZAP to support it properly.
>>>>>>> That could be a useful project?
>>>>>>> And good suggestion for the passwords :)
>>>>>>> Many thanks,
>>>>>>> Simon
>>>>>>> On Friday, 21 September 2012 16:23:12 UTC+1, prasad wrote:
>>>>>>>> Is the weak NTLM v* authentication support in ZAP due to the fact that it is built on Paros? I have always had a problem with the missing or lacking support for NTLM authentication in Paros. Is this a existing feature request? or can be added?
>>>>>>>> Also, I have submitted a feature request to mask the passwords on the Authentication settings page.
> This idea is to mask the passwords via dialogs. That would be on Authentication panel and other places where passwords are requested, in a consistent manner.
> Are you sure I don't need to wait for your code to be committed? There won't be any Mask Password button in the current layout so how do I write a listener to mask/unmask etc? I might be missing something. If so, please help me understand.
> Thank you,
> Prasad N. Shenoy
> On Nov 9, 2012, at 4:50 PM, thc202 <thc...@gmail.com> wrote:
>> Hi.
>> There are some issues that are delaying the commit of the changes, as I wanted to have it already included in the previous weekly release, but you should be able to make the required changes to display the masked password without problems as the model (OptionsAuthenticationTableModel) and panel (OptionsAuthenticationPanel) will be the same, or it's also to be masked in the configuration file?
>> The password should also be masked in the dialogues to add and modify the host authentication?
>> Best regards.
>> On Thursday, 8 November 2012 04:35:29 UTC, prasad wrote:
>>> thc202,
>>> I agree. This looks really good and closer to what I had anticipated. What is the plan now? I would like to work on password masking to begin with.
>>> Thanks
>>> Prasad
>>> On Sep 27, 2012, at 8:14 PM, thc202 <thc...@gmail.com> wrote:
>>>> Hi.
>>>> If I am understanding you correctly, regarding the table model, you only need to implement the methods to add and remove the HostAuthentication(s) in the class OptionsAuthenticationTableModel.
>>>> Curiously, I'm about to finish some changes on how multiple related options are managed (which includes the management of the host authentication) and other details regarding the usability of all the options.
>>>> Currently there are several ways, which can be grouped in 3 categories, on how those options are managed. All of them have some issues that impair the usability, from minor to greater:
>>>> 1) The options are added, removed and edited directly in the table (example: "Session properties" > "Exclude from proxy"). The main problems are: >>>> - to remove an option you have to delete the contents of the cell;
>>>> - (a special annoying one) when editing the options if the cell doesn't loose the focus and you close the dialogue the option doesn't get updated;
>>>> - there's no way to temporarily disable an option (not related to how the management is done, but it's worth remarking it, as most of the multiple related options, if not all, should provide a way to enable/disable them);
>>>> - it may happen that the last row is not always shown immediately to allow the addition of a new entry;
>>>> 2) The options are added, edited and removed with buttons, the fields of those options are shown beneath the table listing the options (example: "Options" > "Applications"). There are minor problems related to how the buttons work and the fields being always editable.
>>>> - If by mistake you press the wrong button (pressing "new" again) it will result in a lose of the additions;
>>>> - the fields are not updated if the keyboard is used (not related to the management, but it's worth pointing, as this is a usability detail that should be taken in consideration);
>>>> 3) The options are managed in a text area, this is, by far, the least usable (example: "Options" > "Connections" > "Skip IP addresses (...)" text area). There's no need to say too much about this way (it, almost, speaks for itself), the user has to manually select the correct option to remove it, which can be hard to pinpoint if you have a lot of those and there's no way to disable an entry.
>>>> Not all the issues are described, but, more or less, the most relevant to the ways of management, are.
>>>> The changes are an attempt to normalise how the management of multiple related options is done throughout ZAP, so, hopefully, the user doesn't have to jump from a way of doing it to another one completely different. It should also allow the user to specify some details of those options, in the case of the "Exclude from proxy", there should be an easy way to specify an URL in plain text without the need to manually "quote" the "regular expression", more over it allows to introduce other conditions not restricted to a specific component of the message like the URL (may be useful if the user wants to exclude files that are greater than a specific size (determined through the "Content-Length" header field)).
>>>> Some of the other details regarding the usability of all the options:
>>>> - When an option is disabled, other options that depend on the disabled option shouldn't be reset. If the user only wanted to disable temporarily the option, he won't need to fill all the fields again (example: "Options" > "Connections" > "Use an outgoing proxy server" if it is unchecked the "Address", "Port" and "Skip IP addresses (...)" are reset);
>>>> - Addition of a button to reset the options to default values.
>>>> - The components should resize correctly when the dialogue is resized (example: "Options" > "Connections" > "Skip IP addresses (...)" the text area doesn't resize as most as it should).
>>>> I also want to allow the user to maximise the "Options" dialogue.
>>>> I was going to commit the changes (when ready) without asking about the changes to the develop group, as there are much more advantages to what is being done now that it seems to me that it's a natural change and that it inevitably would happen (there are some issue(s) about the usability of some options).
>>>> But as this subject as been brought here, I've attached a working example on what the management will look like (if everyone agrees with it). If anyone wants to see it and give some feedback, it would be greatly appreciated.
>>>> Best regards.
>>>> On Wednesday, September 26, 2012 6:31:29 PM UTC+1, prasad wrote:
>>>>> Would there be any objection to changing the look and feel of the authentication options panel? The current one uses AbstractTable and model is not very flexible from what I could deduce. I would like to make the table more dynamic enabling users to add and delete authentication options quickly and easily. I have some ideas but want to get the pulse of the group.
>>>>> Any advice would be appreciated.
>>>>> [ ~ Prasad | @prasadshenoy ~]
>>>>> On Sat, Sep 22, 2012 at 4:07 AM, psiinon <psi...@gmail.com> wrote:
>>>>>> I've assigned the issue to you - go for it!
>>>>>> On Friday, 21 September 2012 18:05:48 UTC+1, prasad wrote:
>>>>>>> I would like to work on the password masking issue item.
>>>>>>> [ ~ Prasad | @prasadshenoy ~]
>>>>>>> On Fri, Sep 21, 2012 at 12:03 PM, psiinon <psi...@gmail.com> wrote:
>>>>>>>> Yes :)
>>>>>>>> I cant see an existing request for it, but feel free to add it!
>>>>>>>> I must admit I dont do any assessments on apps that use NTLM, but it would be really good for ZAP to support it properly.
>>>>>>>> That could be a useful project?
>>>>>>>> And good suggestion for the passwords :)
>>>>>>>> Many thanks,
>>>>>>>> Simon
>>>>>>>> On Friday, 21 September 2012 16:23:12 UTC+1, prasad wrote:
>>>>>>>>> Is the weak NTLM v* authentication support in ZAP due to the fact that it is built on Paros? I have always had a problem with the missing or lacking support for NTLM authentication in Paros. Is this a existing feature request? or can be added?
>>>>>>>>> Also, I have submitted a feature request to mask the passwords on the Authentication settings page.
Sorry for not answering sooner to the previous message.
It was possible to mask the passwords, at least in the table as the dialogues didn't exist, without the need to wait for the changes to be committed because I thought that the button (probably it would be better to use a check box to enable/disable the masking of the passwords) would be added by you to the "Authentication" options panel. The check box that I've added to the previously attached example was only to exemplify where other options, that would affect the managed options, would be placed, it was not meant to be committed.
I've committed the changes that affected the "Authentication" options panel, so you can also change it to mask the passwords in the add/modify dialogues.
Regarding the masking of the passwords, in the table, you could simply return always the same masked string, like "*****", when the option is enabled and return the password in clear text, as it is now, when disabled. About the dialogues it could be changed to show two *JPasswordField*s (which would replace the current text field) when enabled and the current text field when disabled. As for the check box to enable/disable the masking, it would be better to have a warning/confirmation dialogue, when disabling, to warn that the passwords will be in clear text and confirm that it's sure about it.
On Friday, 16 November 2012 14:18:25 UTC, prasad wrote:
> Any thoughts or suggestions on this?
> Thank you, > Prasad N. Shenoy
> On Nov 9, 2012, at 5:36 PM, Prasad Shenoy <prasad...@gmail.com<javascript:>> > wrote:
> This idea is to mask the passwords via dialogs. That would be on > Authentication panel and other places where passwords are requested, in a > consistent manner.
> Are you sure I don't need to wait for your code to be committed? There > won't be any Mask Password button in the current layout so how do I write a > listener to mask/unmask etc? I might be missing something. If so, please > help me understand.
> Thank you, > Prasad N. Shenoy
> On Nov 9, 2012, at 4:50 PM, thc202 <thc...@gmail.com <javascript:>> wrote:
> Hi.
> There are some issues that are delaying the commit of the changes, as I > wanted to have it already included in the previous weekly release, but you > should be able to make the required changes to display the masked password > without problems as the model (*OptionsAuthenticationTableModel*) and > panel (*OptionsAuthenticationPanel*) will be the same, or it's also to be > masked in the configuration file?
> The password should also be masked in the dialogues to add and modify the > host authentication?
> Best regards.
> On Thursday, 8 November 2012 04:35:29 UTC, prasad wrote:
>> thc202,
>> I agree. This looks really good and closer to what I had anticipated. >> What is the plan now? I would like to work on password masking to begin >> with.
>> Thanks >> Prasad
>> On Sep 27, 2012, at 8:14 PM, thc202 <thc...@gmail.com> wrote:
>> Hi.
>> If I am understanding you correctly, regarding the table model, you only >> need to implement the methods to add and remove the *HostAuthentication*(s) >> in the class *OptionsAuthenticationTableModel*.
>> Curiously, I'm about to finish some changes on how multiple related >> options are managed (which includes the management of the host >> authentication) and other details regarding the usability of all the >> options. >> Currently there are several ways, which can be grouped in 3 categories, >> on how those options are managed. All of them have some issues that impair >> the usability, from minor to greater: >> 1) The options are added, removed and edited directly in the table >> (example: "Session properties" > "Exclude from proxy"). The main problems >> are: >> - to remove an option you have to delete the contents of the cell; >> - (a special annoying one) when editing the options if the cell doesn't >> loose the focus and you close the dialogue the option doesn't get updated; >> - there's no way to temporarily disable an option (not related to how >> the management is done, but it's worth remarking it, as most of the >> multiple related options, if not all, should provide a way to >> enable/disable them); >> - it may happen that the last row is not always shown immediately to >> allow the addition of a new entry; >> 2) The options are added, edited and removed with buttons, the fields of >> those options are shown beneath the table listing the options (example: >> "Options" > "Applications"). There are minor problems related to how the >> buttons work and the fields being always editable. >> - If by mistake you press the wrong button (pressing "new" again) it >> will result in a lose of the additions; >> - the fields are not updated if the keyboard is used (not related to >> the management, but it's worth pointing, as this is a usability detail that >> should be taken in consideration); >> 3) The options are managed in a text area, this is, by far, the least >> usable (example: "Options" > "Connections" > "Skip IP addresses (...)" text >> area). There's no need to say too much about this way (it, almost, speaks >> for itself), the user has to manually select the correct option to remove >> it, which can be hard to pinpoint if you have a lot of those and there's no >> way to disable an entry.
>> Not all the issues are described, but, more or less, the most relevant to >> the ways of management, are.
>> The changes are an attempt to normalise how the management of multiple >> related options is done throughout ZAP, so, hopefully, the user doesn't >> have to jump from a way of doing it to another one completely different. It >> should also allow the user to specify some details of those options, in the >> case of the "Exclude from proxy", there should be an easy way to specify an >> URL in plain text without the need to manually "quote" the "regular >> expression", more over it allows to introduce other conditions not >> restricted to a specific component of the message like the URL (may be >> useful if the user wants to exclude files that are greater than a specific >> size (determined through the "Content-Length" header field)).
>> Some of the other details regarding the usability of all the options: >> - When an option is disabled, other options that depend on the disabled >> option shouldn't be reset. If the user only wanted to disable temporarily >> the option, he won't need to fill all the fields again (example: "Options" >> > "Connections" > "Use an outgoing proxy server" if it is unchecked the >> "Address", "Port" and "Skip IP addresses (...)" are reset); >> - Addition of a button to reset the options to default values. >> - The components should resize correctly when the dialogue is resized >> (example: "Options" > "Connections" > "Skip IP addresses (...)" the text >> area doesn't resize as most as it should).
>> I also want to allow the user to maximise the "Options" dialogue.
>> I was going to commit the changes (when ready) without asking about the >> changes to the develop group, as there are much more advantages to what is >> being done now that it seems to me that it's a natural change and that it >> inevitably would happen (there are some issue(s) about the usability of >> some options).
>> But as this subject as been brought here, I've attached a working example >> on what the management will look like (if everyone agrees with it). If >> anyone wants to see it and give some feedback, it would be greatly >> appreciated.
>> Best regards.
>> On Wednesday, September 26, 2012 6:31:29 PM UTC+1, prasad wrote:
>>> Would there be any objection to changing the look and feel of the >>> authentication options panel? The current one uses AbstractTable and model >>> is not very flexible from what I could deduce. I would like to make the >>> table more dynamic enabling users to add and delete authentication options >>> quickly and easily. I have some ideas but want to get the pulse of the >>> group.
>>> Any advice would be appreciated.
>>> [ ~ Prasad | @prasadshenoy ~]
>>> On Sat, Sep 22, 2012 at 4:07 AM, psiinon <psi...@gmail.com> wrote:
>>>> I've assigned the issue to you - go for it!
>>>> On Friday, 21 September 2012 18:05:48 UTC+1, prasad wrote:
>>>>> I would like to work on the password masking issue item.
>>>>> [ ~ Prasad | @prasadshenoy ~]
>>>>> On Fri, Sep 21, 2012 at 12:03 PM, psiinon <psi...@gmail.com> wrote:
>>>>>> On Friday, 21 September 2012 16:23:12 UTC+1, prasad wrote:
>>>>>>> Is the weak NTLM v* authentication support in ZAP due to the fact >>>>>>> that it is built on Paros? I have always had a problem with the missing or >>>>>>> lacking support for NTLM authentication in Paros. Is this a existing >>>>>>> feature request? or can be added?
>>>>>>> Also, I have submitted a feature request to mask the passwords on >>>>>>> the Authentication settings page.
I have made the required changes to the Authentication options panel to be able to mask the password. One question though, for the general population as well - My preference is to leave the password masked (**********) in the table/list view while offering a mask/unmask choice only on the Add/Modify dialog. This is a bit more secure whilst bit inconvenient.
What is the general though on this?
Thanks.
Prasad
On Nov 16, 2012, at 8:49 PM, thc202 <thc...@gmail.com> wrote:
> Sorry for not answering sooner to the previous message.
> It was possible to mask the passwords, at least in the table as the dialogues didn't exist, without the need to wait for the changes to be committed because I thought that the button (probably it would be better to use a check box to enable/disable the masking of the passwords) would be added by you to the "Authentication" options panel. The check box that I've added to the previously attached example was only to exemplify where other options, that would affect the managed options, would be placed, it was not meant to be committed.
> I've committed the changes that affected the "Authentication" options panel, so you can also change it to mask the passwords in the add/modify dialogues.
> Regarding the masking of the passwords, in the table, you could simply return always the same masked string, like "*****", when the option is enabled and return the password in clear text, as it is now, when disabled. About the dialogues it could be changed to show two JPasswordFields (which would replace the current text field) when enabled and the current text field when disabled. As for the check box to enable/disable the masking, it would be better to have a warning/confirmation dialogue, when disabling, to warn that the passwords will be in clear text and confirm that it's sure about it.
> Best regards.
> On Friday, 16 November 2012 14:18:25 UTC, prasad wrote:
> Any thoughts or suggestions on this?
> Thank you,
> Prasad N. Shenoy
> On Nov 9, 2012, at 5:36 PM, Prasad Shenoy <prasad...@gmail.com> wrote:
>> This idea is to mask the passwords via dialogs. That would be on Authentication panel and other places where passwords are requested, in a consistent manner.
>> Are you sure I don't need to wait for your code to be committed? There won't be any Mask Password button in the current layout so how do I write a listener to mask/unmask etc? I might be missing something. If so, please help me understand.
>> Thank you,
>> Prasad N. Shenoy
>> On Nov 9, 2012, at 4:50 PM, thc202 <thc...@gmail.com> wrote:
>>> Hi.
>>> There are some issues that are delaying the commit of the changes, as I wanted to have it already included in the previous weekly release, but you should be able to make the required changes to display the masked password without problems as the model (OptionsAuthenticationTableModel) and panel (OptionsAuthenticationPanel) will be the same, or it's also to be masked in the configuration file?
>>> The password should also be masked in the dialogues to add and modify the host authentication?
>>> Best regards.
>>> On Thursday, 8 November 2012 04:35:29 UTC, prasad wrote:
>>> thc202,
>>> I agree. This looks really good and closer to what I had anticipated. What is the plan now? I would like to work on password masking to begin with.
>>> Thanks
>>> Prasad
>>> On Sep 27, 2012, at 8:14 PM, thc202 <thc...@gmail.com> wrote:
>>>> Hi.
>>>> If I am understanding you correctly, regarding the table model, you only need to implement the methods to add and remove the HostAuthentication(s) in the class OptionsAuthenticationTableModel.
>>>> Curiously, I'm about to finish some changes on how multiple related options are managed (which includes the management of the host authentication) and other details regarding the usability of all the options.
>>>> Currently there are several ways, which can be grouped in 3 categories, on how those options are managed. All of them have some issues that impair the usability, from minor to greater:
>>>> 1) The options are added, removed and edited directly in the table (example: "Session properties" > "Exclude from proxy"). The main problems are: >>>> - to remove an option you have to delete the contents of the cell;
>>>> - (a special annoying one) when editing the options if the cell doesn't loose the focus and you close the dialogue the option doesn't get updated;
>>>> - there's no way to temporarily disable an option (not related to how the management is done, but it's worth remarking it, as most of the multiple related options, if not all, should provide a way to enable/disable them);
>>>> - it may happen that the last row is not always shown immediately to allow the addition of a new entry;
>>>> 2) The options are added, edited and removed with buttons, the fields of those options are shown beneath the table listing the options (example: "Options" > "Applications"). There are minor problems related to how the buttons work and the fields being always editable.
>>>> - If by mistake you press the wrong button (pressing "new" again) it will result in a lose of the additions;
>>>> - the fields are not updated if the keyboard is used (not related to the management, but it's worth pointing, as this is a usability detail that should be taken in consideration);
>>>> 3) The options are managed in a text area, this is, by far, the least usable (example: "Options" > "Connections" > "Skip IP addresses (...)" text area). There's no need to say too much about this way (it, almost, speaks for itself), the user has to manually select the correct option to remove it, which can be hard to pinpoint if you have a lot of those and there's no way to disable an entry.
>>>> Not all the issues are described, but, more or less, the most relevant to the ways of management, are.
>>>> The changes are an attempt to normalise how the management of multiple related options is done throughout ZAP, so, hopefully, the user doesn't have to jump from a way of doing it to another one completely different. It should also allow the user to specify some details of those options, in the case of the "Exclude from proxy", there should be an easy way to specify an URL in plain text without the need to manually "quote" the "regular expression", more over it allows to introduce other conditions not restricted to a specific component of the message like the URL (may be useful if the user wants to exclude files that are greater than a specific size (determined through the "Content-Length" header field)).
>>>> Some of the other details regarding the usability of all the options:
>>>> - When an option is disabled, other options that depend on the disabled option shouldn't be reset. If the user only wanted to disable temporarily the option, he won't need to fill all the fields again (example: "Options" > "Connections" > "Use an outgoing proxy server" if it is unchecked the "Address", "Port" and "Skip IP addresses (...)" are reset);
>>>> - Addition of a button to reset the options to default values.
>>>> - The components should resize correctly when the dialogue is resized (example: "Options" > "Connections" > "Skip IP addresses (...)" the text area doesn't resize as most as it should).
>>>> I also want to allow the user to maximise the "Options" dialogue.
>>>> I was going to commit the changes (when ready) without asking about the changes to the develop group, as there are much more advantages to what is being done now that it seems to me that it's a natural change and that it inevitably would happen (there are some issue(s) about the usability of some options).
>>>> But as this subject as been brought here, I've attached a working example on what the management will look like (if everyone agrees with it). If anyone wants to see it and give some feedback, it would be greatly appreciated.
>>>> Best regards.
>>>> On Wednesday, September 26, 2012 6:31:29 PM UTC+1, prasad wrote:
>>>> Would there be any objection to changing the look and feel of the authentication options panel? The current one uses AbstractTable and model is not very flexible from what I could deduce. I would like to make the table more dynamic enabling users to add and delete authentication options quickly and easily. I have some ideas but want to get the pulse of the group.
>>>> Any advice would be appreciated.
>>>> [ ~ Prasad | @prasadshenoy ~]
>>>> On Sat, Sep 22, 2012 at 4:07 AM, psiinon <psi...@gmail.com> wrote:
>>>> I've assigned the issue to you - go for it!
>>>> On Friday, 21 September 2012 18:05:48 UTC+1, prasad wrote:
>>>> I would like to work on the password masking issue item.
>>>> [ ~ Prasad | @prasadshenoy ~]
>>>> On Fri, Sep 21, 2012 at 12:03 PM, psiinon <psi...@gmail.com> wrote:
>>>> Yes :)
>>>> I cant see an existing request for it, but feel free to add it!
>>>> I must admit I dont do any assessments on apps that use NTLM, but it would be really good for ZAP to support it properly.
>>>> That could be a useful project?
>>>> And good suggestion for the passwords :)
>>>> Many thanks,
>>>> Simon
>>>> On Friday, 21 September 2012 16:23:12 UTC+1, prasad wrote:
>>>> Is the weak NTLM v* authentication support in ZAP due to the fact that it is built on Paros? I have always had a problem with the missing or lacking support for NTLM authentication in Paros. Is this a existing feature request? or can be added?
>>>> Also, I have submitted a feature request to mask the passwords on the Authentication settings page.
On Tuesday, 27 November 2012 21:50:10 UTC, prasad wrote:
> THC202,
> Thanks. That was helpful.
> I have made the required changes to the Authentication options panel to be > able to mask the password. One question though, for the general population > as well - My preference is to leave the password masked (**********) in the > table/list view while offering a mask/unmask choice only on the Add/Modify > dialog. This is a bit more secure whilst bit inconvenient.
> What is the general though on this?
> Thanks. > Prasad
> On Nov 16, 2012, at 8:49 PM, thc202 <thc...@gmail.com <javascript:>> > wrote:
> Hi.
> Sorry for not answering sooner to the previous message.
> It was possible to mask the passwords, at least in the table as the > dialogues didn't exist, without the need to wait for the changes to be > committed because I thought that the button (probably it would be better to > use a check box to enable/disable the masking of the passwords) would be > added by you to the "Authentication" options panel. The check box that I've > added to the previously attached example was only to exemplify where other > options, that would affect the managed options, would be placed, it was not > meant to be committed.
> I've committed the changes that affected the "Authentication" options > panel, so you can also change it to mask the passwords in the add/modify > dialogues.
> Regarding the masking of the passwords, in the table, you could simply > return always the same masked string, like "*****", when the option is > enabled and return the password in clear text, as it is now, when disabled. > About the dialogues it could be changed to show two *JPasswordField*s > (which would replace the current text field) when enabled and the current > text field when disabled. As for the check box to enable/disable the > masking, it would be better to have a warning/confirmation dialogue, when > disabling, to warn that the passwords will be in clear text and confirm > that it's sure about it.
> Best regards.
> On Friday, 16 November 2012 14:18:25 UTC, prasad wrote:
>> Any thoughts or suggestions on this?
>> Thank you, >> Prasad N. Shenoy
>> On Nov 9, 2012, at 5:36 PM, Prasad Shenoy <prasad...@gmail.com> wrote:
>> This idea is to mask the passwords via dialogs. That would be on >> Authentication panel and other places where passwords are requested, in a >> consistent manner.
>> Are you sure I don't need to wait for your code to be committed? There >> won't be any Mask Password button in the current layout so how do I write a >> listener to mask/unmask etc? I might be missing something. If so, please >> help me understand.
>> Thank you, >> Prasad N. Shenoy
>> On Nov 9, 2012, at 4:50 PM, thc202 <thc...@gmail.com> wrote:
>> Hi.
>> There are some issues that are delaying the commit of the changes, as I >> wanted to have it already included in the previous weekly release, but you >> should be able to make the required changes to display the masked password >> without problems as the model (*OptionsAuthenticationTableModel*) and >> panel (*OptionsAuthenticationPanel*) will be the same, or it's also to >> be masked in the configuration file?
>> The password should also be masked in the dialogues to add and modify the >> host authentication?
>> Best regards.
>> On Thursday, 8 November 2012 04:35:29 UTC, prasad wrote:
>>> thc202,
>>> I agree. This looks really good and closer to what I had anticipated. >>> What is the plan now? I would like to work on password masking to begin >>> with.
>>> Thanks >>> Prasad
>>> On Sep 27, 2012, at 8:14 PM, thc202 <thc...@gmail.com> wrote:
>>> Hi.
>>> If I am understanding you correctly, regarding the table model, you only >>> need to implement the methods to add and remove the *HostAuthentication*(s) >>> in the class *OptionsAuthenticationTableModel*.
>>> Curiously, I'm about to finish some changes on how multiple related >>> options are managed (which includes the management of the host >>> authentication) and other details regarding the usability of all the >>> options. >>> Currently there are several ways, which can be grouped in 3 categories, >>> on how those options are managed. All of them have some issues that impair >>> the usability, from minor to greater: >>> 1) The options are added, removed and edited directly in the table >>> (example: "Session properties" > "Exclude from proxy"). The main problems >>> are: >>> - to remove an option you have to delete the contents of the cell; >>> - (a special annoying one) when editing the options if the cell >>> doesn't loose the focus and you close the dialogue the option doesn't get >>> updated; >>> - there's no way to temporarily disable an option (not related to how >>> the management is done, but it's worth remarking it, as most of the >>> multiple related options, if not all, should provide a way to >>> enable/disable them); >>> - it may happen that the last row is not always shown immediately to >>> allow the addition of a new entry; >>> 2) The options are added, edited and removed with buttons, the fields >>> of those options are shown beneath the table listing the options (example: >>> "Options" > "Applications"). There are minor problems related to how the >>> buttons work and the fields being always editable. >>> - If by mistake you press the wrong button (pressing "new" again) it >>> will result in a lose of the additions; >>> - the fields are not updated if the keyboard is used (not related to >>> the management, but it's worth pointing, as this is a usability detail that >>> should be taken in consideration); >>> 3) The options are managed in a text area, this is, by far, the least >>> usable (example: "Options" > "Connections" > "Skip IP addresses (...)" text >>> area). There's no need to say too much about this way (it, almost, speaks >>> for itself), the user has to manually select the correct option to remove >>> it, which can be hard to pinpoint if you have a lot of those and there's no >>> way to disable an entry.
>>> Not all the issues are described, but, more or less, the most relevant >>> to the ways of management, are.
>>> The changes are an attempt to normalise how the management of multiple >>> related options is done throughout ZAP, so, hopefully, the user doesn't >>> have to jump from a way of doing it to another one completely different. It >>> should also allow the user to specify some details of those options, in the >>> case of the "Exclude from proxy", there should be an easy way to specify an >>> URL in plain text without the need to manually "quote" the "regular >>> expression", more over it allows to introduce other conditions not >>> restricted to a specific component of the message like the URL (may be >>> useful if the user wants to exclude files that are greater than a specific >>> size (determined through the "Content-Length" header field)).
>>> Some of the other details regarding the usability of all the options: >>> - When an option is disabled, other options that depend on the disabled >>> option shouldn't be reset. If the user only wanted to disable temporarily >>> the option, he won't need to fill all the fields again (example: "Options" >>> > "Connections" > "Use an outgoing proxy server" if it is unchecked the >>> "Address", "Port" and "Skip IP addresses (...)" are reset); >>> - Addition of a button to reset the options to default values. >>> - The components should resize correctly when the dialogue is resized >>> (example: "Options" > "Connections" > "Skip IP addresses (...)" the text >>> area doesn't resize as most as it should).
>>> I also want to allow the user to maximise the "Options" dialogue.
>>> I was going to commit the changes (when ready) without asking about the >>> changes to the develop group, as there are much more advantages to what is >>> being done now that it seems to me that it's a natural change and that it >>> inevitably would happen (there are some issue(s) about the usability of >>> some options).
>>> But as this subject as been brought here, I've attached a working >>> example on what the management will look like (if everyone agrees with it). >>> If anyone wants to see it and give some feedback, it would be greatly >>> appreciated.
>>> Best regards.
>>> On Wednesday, September 26, 2012 6:31:29 PM UTC+1, prasad wrote:
>>>> Would there be any objection to changing the look and feel of the >>>> authentication options panel? The current one uses AbstractTable and model >>>> is not very flexible from what I could deduce. I would like to make the >>>> table more dynamic enabling users to add and delete authentication options >>>> quickly and easily. I have some ideas but want to get the pulse of the >>>> group.
>>>> Any advice would be appreciated.
>>>> [ ~ Prasad | @prasadshenoy ~]
>>>> On Sat, Sep 22, 2012 at 4:07 AM, psiinon <psi...@gmail.com> wrote:
>>>>> I've assigned the issue to you - go for it!
>>>>> On Friday, 21 September 2012 18:05:48 UTC+1, prasad wrote:
>>>>>> I would like to work on the password masking issue item.
>>>>>> [ ~ Prasad | @prasadshenoy ~]
>>>>>> On Fri, Sep 21, 2012 at 12:03 PM, psiinon <psi...@gmail.com> wrote:
>>>>>>> Yes :) >>>>>>> I cant see an existing request for it, but feel free to add it<http://code.google.com/p/zaproxy/issues/entry> >>>>>>> ! >>>>>>> I must admit I dont do any assessments on apps that use NTLM, but it >>>>>>> would be really good for ZAP to support it properly. >>>>>>> That could be a useful project<http://code.google.com/p/zaproxy/wiki/Projects>?
Yeah, I think we should have an option for showing the passwords. Maybe we could have a checkbox in the Options/Display screen? I dont mind which way round the default is.
On Friday, 30 November 2012 15:29:06 UTC, thc202 wrote:
> Hi.
> I would still allow the current behaviour, that is, show the passwords in > clear text in the table.
> Best regards.
> On Tuesday, 27 November 2012 21:50:10 UTC, prasad wrote:
>> THC202,
>> Thanks. That was helpful.
>> I have made the required changes to the Authentication options panel to >> be able to mask the password. One question though, for the general >> population as well - My preference is to leave the password masked >> (**********) in the table/list view while offering a mask/unmask choice >> only on the Add/Modify dialog. This is a bit more secure whilst bit >> inconvenient.
>> What is the general though on this?
>> Thanks. >> Prasad
>> On Nov 16, 2012, at 8:49 PM, thc202 <thc...@gmail.com> wrote:
>> Hi.
>> Sorry for not answering sooner to the previous message.
>> It was possible to mask the passwords, at least in the table as the >> dialogues didn't exist, without the need to wait for the changes to be >> committed because I thought that the button (probably it would be better to >> use a check box to enable/disable the masking of the passwords) would be >> added by you to the "Authentication" options panel. The check box that I've >> added to the previously attached example was only to exemplify where other >> options, that would affect the managed options, would be placed, it was not >> meant to be committed.
>> I've committed the changes that affected the "Authentication" options >> panel, so you can also change it to mask the passwords in the add/modify >> dialogues.
>> Regarding the masking of the passwords, in the table, you could simply >> return always the same masked string, like "*****", when the option is >> enabled and return the password in clear text, as it is now, when disabled. >> About the dialogues it could be changed to show two *JPasswordField*s >> (which would replace the current text field) when enabled and the current >> text field when disabled. As for the check box to enable/disable the >> masking, it would be better to have a warning/confirmation dialogue, when >> disabling, to warn that the passwords will be in clear text and confirm >> that it's sure about it.
>> Best regards.
>> On Friday, 16 November 2012 14:18:25 UTC, prasad wrote:
>>> Any thoughts or suggestions on this?
>>> Thank you, >>> Prasad N. Shenoy
>>> On Nov 9, 2012, at 5:36 PM, Prasad Shenoy <prasad...@gmail.com> wrote:
>>> This idea is to mask the passwords via dialogs. That would be on >>> Authentication panel and other places where passwords are requested, in a >>> consistent manner.
>>> Are you sure I don't need to wait for your code to be committed? There >>> won't be any Mask Password button in the current layout so how do I write a >>> listener to mask/unmask etc? I might be missing something. If so, please >>> help me understand.
>>> Thank you, >>> Prasad N. Shenoy
>>> On Nov 9, 2012, at 4:50 PM, thc202 <thc...@gmail.com> wrote:
>>> Hi.
>>> There are some issues that are delaying the commit of the changes, as I >>> wanted to have it already included in the previous weekly release, but you >>> should be able to make the required changes to display the masked password >>> without problems as the model (*OptionsAuthenticationTableModel*) and >>> panel (*OptionsAuthenticationPanel*) will be the same, or it's also to >>> be masked in the configuration file?
>>> The password should also be masked in the dialogues to add and modify >>> the host authentication?
>>> Best regards.
>>> On Thursday, 8 November 2012 04:35:29 UTC, prasad wrote:
>>>> thc202,
>>>> I agree. This looks really good and closer to what I had anticipated. >>>> What is the plan now? I would like to work on password masking to begin >>>> with.
>>>> Thanks >>>> Prasad
>>>> On Sep 27, 2012, at 8:14 PM, thc202 <thc...@gmail.com> wrote:
>>>> Hi.
>>>> If I am understanding you correctly, regarding the table model, you >>>> only need to implement the methods to add and remove the * >>>> HostAuthentication*(s) in the class *OptionsAuthenticationTableModel*.
>>>> Curiously, I'm about to finish some changes on how multiple related >>>> options are managed (which includes the management of the host >>>> authentication) and other details regarding the usability of all the >>>> options. >>>> Currently there are several ways, which can be grouped in 3 categories, >>>> on how those options are managed. All of them have some issues that impair >>>> the usability, from minor to greater: >>>> 1) The options are added, removed and edited directly in the table >>>> (example: "Session properties" > "Exclude from proxy"). The main problems >>>> are: >>>> - to remove an option you have to delete the contents of the cell; >>>> - (a special annoying one) when editing the options if the cell >>>> doesn't loose the focus and you close the dialogue the option doesn't get >>>> updated; >>>> - there's no way to temporarily disable an option (not related to how >>>> the management is done, but it's worth remarking it, as most of the >>>> multiple related options, if not all, should provide a way to >>>> enable/disable them); >>>> - it may happen that the last row is not always shown immediately to >>>> allow the addition of a new entry; >>>> 2) The options are added, edited and removed with buttons, the fields >>>> of those options are shown beneath the table listing the options (example: >>>> "Options" > "Applications"). There are minor problems related to how the >>>> buttons work and the fields being always editable. >>>> - If by mistake you press the wrong button (pressing "new" again) it >>>> will result in a lose of the additions; >>>> - the fields are not updated if the keyboard is used (not related to >>>> the management, but it's worth pointing, as this is a usability detail that >>>> should be taken in consideration); >>>> 3) The options are managed in a text area, this is, by far, the least >>>> usable (example: "Options" > "Connections" > "Skip IP addresses (...)" text >>>> area). There's no need to say too much about this way (it, almost, speaks >>>> for itself), the user has to manually select the correct option to remove >>>> it, which can be hard to pinpoint if you have a lot of those and there's no >>>> way to disable an entry.
>>>> Not all the issues are described, but, more or less, the most relevant >>>> to the ways of management, are.
>>>> The changes are an attempt to normalise how the management of multiple >>>> related options is done throughout ZAP, so, hopefully, the user doesn't >>>> have to jump from a way of doing it to another one completely different. It >>>> should also allow the user to specify some details of those options, in the >>>> case of the "Exclude from proxy", there should be an easy way to specify an >>>> URL in plain text without the need to manually "quote" the "regular >>>> expression", more over it allows to introduce other conditions not >>>> restricted to a specific component of the message like the URL (may be >>>> useful if the user wants to exclude files that are greater than a specific >>>> size (determined through the "Content-Length" header field)).
>>>> Some of the other details regarding the usability of all the options: >>>> - When an option is disabled, other options that depend on the >>>> disabled option shouldn't be reset. If the user only wanted to disable >>>> temporarily the option, he won't need to fill all the fields again >>>> (example: "Options" > "Connections" > "Use an outgoing proxy server" if it >>>> is unchecked the "Address", "Port" and "Skip IP addresses (...)" are reset); >>>> - Addition of a button to reset the options to default values. >>>> - The components should resize correctly when the dialogue is resized >>>> (example: "Options" > "Connections" > "Skip IP addresses (...)" the text >>>> area doesn't resize as most as it should).
>>>> I also want to allow the user to maximise the "Options" dialogue.
>>>> I was going to commit the changes (when ready) without asking about the >>>> changes to the develop group, as there are much more advantages to what is >>>> being done now that it seems to me that it's a natural change and that it >>>> inevitably would happen (there are some issue(s) about the usability of >>>> some options).
>>>> But as this subject as been brought here, I've attached a working >>>> example on what the management will look like (if everyone agrees with it). >>>> If anyone wants to see it and give some feedback, it would be greatly >>>> appreciated.
>>>> Best regards.
>>>> On Wednesday, September 26, 2012 6:31:29 PM UTC+1, prasad wrote:
>>>>> Would there be any objection to changing the look and feel of the >>>>> authentication options panel? The current one uses AbstractTable and model >>>>> is not very flexible from what I could deduce. I would like to make the >>>>> table more dynamic enabling users to add and delete authentication options >>>>> quickly and easily. I have some ideas but want to get the pulse of the >>>>> group.
>>>>> Any advice would be appreciated.
>>>>> [ ~ Prasad | @prasadshenoy ~]
>>>>> On Sat, Sep 22, 2012 at 4:07 AM, psiinon <psi...@gmail.com> wrote:
>>>>>> I've assigned the issue to you - go for it!
>>>>>> On Friday, 21 September 2012 18:05:48 UTC+1, prasad wrote:
>>>>>>> I would like to work on the password masking issue item.
Oh yeah for sure, there needs to be a way to see the clear text password. My question was more around whether there needs to be that provision in the Add/Modify dialog or also on the table that lists all authentication options. In that regards, I followed THC's advice and am building the option in the table view as well.
Will get back in touch shortly.
Thank you
Prasad
On Dec 3, 2012, at 6:56 AM, psiinon <psii...@gmail.com> wrote:
> Yeah, I think we should have an option for showing the passwords.
> Maybe we could have a checkbox in the Options/Display screen?
> I dont mind which way round the default is.
> Cheers,
> Simon
> On Friday, 30 November 2012 15:29:06 UTC, thc202 wrote:
> Hi.
> I would still allow the current behaviour, that is, show the passwords in clear text in the table.
> Best regards.
> On Tuesday, 27 November 2012 21:50:10 UTC, prasad wrote:
> THC202,
> Thanks. That was helpful.
> I have made the required changes to the Authentication options panel to be able to mask the password. One question though, for the general population as well - My preference is to leave the password masked (**********) in the table/list view while offering a mask/unmask choice only on the Add/Modify dialog. This is a bit more secure whilst bit inconvenient.
> What is the general though on this?
> Thanks.
> Prasad
> On Nov 16, 2012, at 8:49 PM, thc202 <thc...@gmail.com> wrote:
>> Hi.
>> Sorry for not answering sooner to the previous message.
>> It was possible to mask the passwords, at least in the table as the dialogues didn't exist, without the need to wait for the changes to be committed because I thought that the button (probably it would be better to use a check box to enable/disable the masking of the passwords) would be added by you to the "Authentication" options panel. The check box that I've added to the previously attached example was only to exemplify where other options, that would affect the managed options, would be placed, it was not meant to be committed.
>> I've committed the changes that affected the "Authentication" options panel, so you can also change it to mask the passwords in the add/modify dialogues.
>> Regarding the masking of the passwords, in the table, you could simply return always the same masked string, like "*****", when the option is enabled and return the password in clear text, as it is now, when disabled. About the dialogues it could be changed to show two JPasswordFields (which would replace the current text field) when enabled and the current text field when disabled. As for the check box to enable/disable the masking, it would be better to have a warning/confirmation dialogue, when disabling, to warn that the passwords will be in clear text and confirm that it's sure about it.
>> Best regards.
>> On Friday, 16 November 2012 14:18:25 UTC, prasad wrote:
>> Any thoughts or suggestions on this?
>> Thank you,
>> Prasad N. Shenoy
>> On Nov 9, 2012, at 5:36 PM, Prasad Shenoy <prasad...@gmail.com> wrote:
>>> This idea is to mask the passwords via dialogs. That would be on Authentication panel and other places where passwords are requested, in a consistent manner.
>>> Are you sure I don't need to wait for your code to be committed? There won't be any Mask Password button in the current layout so how do I write a listener to mask/unmask etc? I might be missing something. If so, please help me understand.
>>> Thank you,
>>> Prasad N. Shenoy
>>> On Nov 9, 2012, at 4:50 PM, thc202 <thc...@gmail.com> wrote:
>>>> Hi.
>>>> There are some issues that are delaying the commit of the changes, as I wanted to have it already included in the previous weekly release, but you should be able to make the required changes to display the masked password without problems as the model (OptionsAuthenticationTableModel) and panel (OptionsAuthenticationPanel) will be the same, or it's also to be masked in the configuration file?
>>>> The password should also be masked in the dialogues to add and modify the host authentication?
>>>> Best regards.
>>>> On Thursday, 8 November 2012 04:35:29 UTC, prasad wrote:
>>>> thc202,
>>>> I agree. This looks really good and closer to what I had anticipated. What is the plan now? I would like to work on password masking to begin with.
>>>> Thanks
>>>> Prasad
>>>> On Sep 27, 2012, at 8:14 PM, thc202 <thc...@gmail.com> wrote:
>>>>> Hi.
>>>>> If I am understanding you correctly, regarding the table model, you only need to implement the methods to add and remove the HostAuthentication(s) in the class OptionsAuthenticationTableModel.
>>>>> Curiously, I'm about to finish some changes on how multiple related options are managed (which includes the management of the host authentication) and other details regarding the usability of all the options.
>>>>> Currently there are several ways, which can be grouped in 3 categories, on how those options are managed. All of them have some issues that impair the usability, from minor to greater:
>>>>> 1) The options are added, removed and edited directly in the table (example: "Session properties" > "Exclude from proxy"). The main problems are: >>>>> - to remove an option you have to delete the contents of the cell;
>>>>> - (a special annoying one) when editing the options if the cell doesn't loose the focus and you close the dialogue the option doesn't get updated;
>>>>> - there's no way to temporarily disable an option (not related to how the management is done, but it's worth remarking it, as most of the multiple related options, if not all, should provide a way to enable/disable them);
>>>>> - it may happen that the last row is not always shown immediately to allow the addition of a new entry;
>>>>> 2) The options are added, edited and removed with buttons, the fields of those options are shown beneath the table listing the options (example: "Options" > "Applications"). There are minor problems related to how the buttons work and the fields being always editable.
>>>>> - If by mistake you press the wrong button (pressing "new" again) it will result in a lose of the additions;
>>>>> - the fields are not updated if the keyboard is used (not related to the management, but it's worth pointing, as this is a usability detail that should be taken in consideration);
>>>>> 3) The options are managed in a text area, this is, by far, the least usable (example: "Options" > "Connections" > "Skip IP addresses (...)" text area). There's no need to say too much about this way (it, almost, speaks for itself), the user has to manually select the correct option to remove it, which can be hard to pinpoint if you have a lot of those and there's no way to disable an entry.
>>>>> Not all the issues are described, but, more or less, the most relevant to the ways of management, are.
>>>>> The changes are an attempt to normalise how the management of multiple related options is done throughout ZAP, so, hopefully, the user doesn't have to jump from a way of doing it to another one completely different. It should also allow the user to specify some details of those options, in the case of the "Exclude from proxy", there should be an easy way to specify an URL in plain text without the need to manually "quote" the "regular expression", more over it allows to introduce other conditions not restricted to a specific component of the message like the URL (may be useful if the user wants to exclude files that are greater than a specific size (determined through the "Content-Length" header field)).
>>>>> Some of the other details regarding the usability of all the options:
>>>>> - When an option is disabled, other options that depend on the disabled option shouldn't be reset. If the user only wanted to disable temporarily the option, he won't need to fill all the fields again (example: "Options" > "Connections" > "Use an outgoing proxy server" if it is unchecked the "Address", "Port" and "Skip IP addresses (...)" are reset);
>>>>> - Addition of a button to reset the options to default values.
>>>>> - The components should resize correctly when the dialogue is resized (example: "Options" > "Connections" > "Skip IP addresses (...)" the text area doesn't resize as most as it should).
>>>>> I also want to allow the user to maximise the "Options" dialogue.
>>>>> I was going to commit the changes (when ready) without asking about the changes to the develop group, as there are much more advantages to what is being done now that it seems to me that it's a natural change and that it inevitably would happen (there are some issue(s) about the usability of some options).
>>>>> But as this subject as been brought here, I've attached a working example on what the management will look like (if everyone agrees with it). If anyone wants to see it and give some feedback, it would be greatly appreciated.
>>>>> Best regards.
>>>>> On Wednesday, September 26, 2012 6:31:29 PM UTC+1, prasad wrote:
>>>>> Would there be any objection to changing the look and feel of the authentication options panel? The current one uses AbstractTable and model is not very flexible from what I could deduce. I would like to make the table more dynamic enabling users to add and delete authentication options quickly and easily. I have some ideas but want to get the pulse of the group.
>>>>> Any advice would be appreciated.
>>>>> [ ~ Prasad | @prasadshenoy ~]
>>>>> On Sat, Sep 22, 2012 at 4:07 AM, psiinon <psi...@gmail.com> wrote:
>>>>> I've assigned the issue to you - go for it!
>>>>> On Friday, 21 September 2012 18:05:48 UTC+1, prasad wrote:
>>>>> I would like to work on the password masking
