SmartGWT version: v8.3d_2012-10-24/PowerEdition Deployment 2012-10-24
Browser: not sure this is applicable as its server side
Scenario:
I'm using a SQLDataSource's fetch operation to perform a user login. The login form fires the DMI, my train of thought it is:
0) User form sends username and password
1) The DMI saves a copy of the password the user entered
2) The password is removed from the criteria
3) dsRequest.execute() as per usual against the username only
4) The returned record will have the hashed password from the database
5) DMI checks the user's password against the hashed password (fyi: BCrypt.checkpw)
I wanted to make sure the password isn't accidentally leaked out by the datasource somehow, so the output is specified in the operation binding:
And the DMI:
However, it seems that even with the inclusion of dsRequest.setOutputs(null), the data that is returned from the dsRequest.execute is missing the password field.
Specifically setting field names into setOutputs has no effect either.
Javadoc for setOutputs:
From what I can see, it seems setOutput is still being restricted to what has been set in the operation binding. I can reduce the list specified in the operation binding, but not include a field that wasn't already there.
The javadoc above seems to suggest otherwise, please let me know if I've understood this.
Aside: why does dsRequest.setOutputs return a DSRequest? Doesn't setOutputs work in-place?
Browser: not sure this is applicable as its server side
Scenario:
I'm using a SQLDataSource's fetch operation to perform a user login. The login form fires the DMI, my train of thought it is:
0) User form sends username and password
1) The DMI saves a copy of the password the user entered
2) The password is removed from the criteria
3) dsRequest.execute() as per usual against the username only
4) The returned record will have the hashed password from the database
5) DMI checks the user's password against the hashed password (fyi: BCrypt.checkpw)
I wanted to make sure the password isn't accidentally leaked out by the datasource somehow, so the output is specified in the operation binding:
Code:
<DataSource ID="user" serverType="sql" tableName="user" autoDeriveSchema="true"> <operationBindings> <!-- login operation uses UserDMI for login --> <operationBinding operationType="fetch" operationId="login" outputs="id,username"> <serverObject className="com.test.UserDMI" methodName="login"/> </operationBinding> </operationBindings> </DataSource>
Code:
public DSResponse login(DSRequest dsRequest, HttpSession session) throws Exception { // get the password from the client String clientPassword = String.valueOf(dsRequest.getCriteria().get("password")); // use the datasource to fetch for the user using the username only dsRequest.getCriteria().remove("password"); // add the password back into outputs for BCrypt dsRequest = dsRequest.setOutputs(null); DSResponse response = dsRequest.execute(); List data = response.getDataList(); // do more stuff here }
Specifically setting field names into setOutputs has no effect either.
Javadoc for setOutputs:
This method is called during DSRequest construction to set the list of output fields requested by the client, or configured in the operationBinding. Therefore, you can call this method from a DMI, custom DataSource or other custom server side code to override the output fields requested by the client or configured declaratively.
The javadoc above seems to suggest otherwise, please let me know if I've understood this.
Aside: why does dsRequest.setOutputs return a DSRequest? Doesn't setOutputs work in-place?