search

PILLUTLAAVINASH / google-enterprise-connector-manager

Automatically exported from code.google.com/p/google-enterprise-connector-manager
0 stars 0 forks source link

During Connector Configuration operations, if there is a problem with the form, the sensitive fields are mangled #152

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Using the GSA create a connector but enter a bad form element so the
Connector won't be valid.  Also enter a good value for a sensitive field
like the password.
2. Submit the config and then you get the form back with an error
indicating that one of the fields needs to be fixed.  At this point the
value entered for the sensitive field has been obfuscated.
3. Fix the bad field and submit again.

What is the expected output? What do you see instead?

The Connector will now be created with the obfuscated value of the
sensitive field rather than the initially entered value.  Since the
password is not correct, the Connector can't authenticate itself to the
content repository and won't work.

It is expected that the originally entered value for the sensitive data be
preserved during the process.

Original issue reported on code.google.com by mgron...@gmail.com on 13 May 2009 at 9:28

GoogleCodeExporter commented 8 years ago 
There are a couple of possible solutions for this:

1. Every time the Connector creates a response related to a bad configuration it
always clears out any sensitive fields.  Don't like this because the user may no
notice that the sensitive fields have been cleared out and get a new error when 
they
submit.  Also, it's inconvenient to ask them to reenter the data each time the 
form
is returned during the initial configuration.  Finally, it makes the Connector
developers maintain a separate rule for sensitive data during connector 
validation.

2.  Don't obfuscate the data during the SetConnectorConfig process.  If the
connection is protected with SSL then there's no issue.  If not, this still 
seems
reasonable since the sensitive data will be exposed during the POST anyway.  
Sending
it back if there's a problem with the config isn't adding any exposure.  The 
other
Servlets will still protect the sensitive data so it can't be queried.

Original comment by mgron...@gmail.com on 13 May 2009 at 9:37

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Fixed.

r1993 | mgronber | 2009-05-15 08:38:54 -0700 (Fri, 15 May 2009) | 22 lines

Fix for Issue 152.  Adding the ability to control the obfuscation on the form
snippet within a ConfigureResponse so it can be turned off when the Connector is
initially being created.  In the creation (non-update) mode the obfuscated data
can't be recovered.

TESTS_PASSED:
  - All Unit Tests.
  - Tested on GSA using TestConnectorA.

M java/com/google/enterprise/connector/servlet/ConnectorManagerGetServlet.java:
  - Added an extension to the writeConfigureResponse() method that takes an
    optional doObfuscate parameter to control if the sensitive form values are
    obfuscated in the response.

M java/com/google/enterprise/connector/servlet/SetConnectorConfig.java:
  - Call the new extended writeConfigureResponse() method using the update
    setting on the Handler to determine if the sensitive data should be
    obfuscated.

M java/com/google/enterprise/connector/spi/SimpleConnectorType.java:
  - Preserved the password value when creating the config form.

Original comment by mgron...@gmail.com on 15 May 2009 at 3:47

GoogleCodeExporter commented 8 years ago

Original comment by Brett.Mi...@gmail.com on 16 May 2009 at 9:16