I have a webgrid that contains a password field - in order to hide the input when editing this field - I execture the following section of code;
If ruleEncrypt IsNot Nothing Then
aGridColToProcess.Type = ColumnType.Custom
Me.WebTextEdit1.Visible = True
However, the minute the user clicks off the cell - the original field is shown and the password they have just typed shows as free text. Is there a way to always show the editor column on top of the original field - or another way to change the grid cell so that text is always hidden?
End If
I have exactly the same issue. Has anyone come up with a workable solution for this?
I have tried embedding a WebTextEdit in Password Mode in a templated column as well, but the cell doesn't get flagged to be updated during batch updates, so I'm guessing that the cell value isn't being updated.
I had added a client-side script to handle the Update event, as follows:
function WebTextEdit1_ValueChange(oEdit, oldValue, oEvent) { var thisCell = igtbl_getActiveRow("MyGrid").getCellFromKey("NewPassword"); if (thisCell != null) { thisCell.Value = oEdit.getText(); } }
...and it's behaving oddly... In that it sometimes shows the plain text (non-bulleted) password in the cell when the focus leaves the cell in the templated column.
Any ideas?
HelloYou can use the property PasswordMode of WebTextEdit <igtxt:WebTextEdit ID="webtextedit1" runat="server" PasswordMode="true"> </igtxt:WebTextEdit> <igtbl:UltraWebGrid ID="UltraWebGrid1" runat="server" DataSourceID="SqlDataSource1"> <Bands> <igtbl:UltraGridBand> <Columns> <igtbl:UltraGridColumn EditorControlID="webtextedit1" Type="Custom" BaseColumnName="LastName" IsBound="True" Key="LastName"> ...
This work properly in 8.3. What am I missing?Thanks.
Thank you for your response, Ivan.
I have the same issue as J_Young has if I use the EditorControlID with a WebTextEdit control in password mode: The text of the password appears as soon as the user clicks on another cell. Mind you, our project is using 5.1. Does that not happen in 8.3?
What I ended up doing is this: I went back to using the EditorControlID (non-templated column) and created another keyed hidden column in the grid. From there, I used the BeforeExitEditModeHandler event of the grid, and added this client-side code:
function MyGrid_BeforeExitEditModeHandler(gridName, cellId){ var row = igtbl_getRowById(cellId); var theCell = igtbl_getCellById(cellId); var theHiddenCell = row.getCellFromKey("MyHiddenPasswordColumn"); if ((theCell.Column.Key == "MyNewPasswordColumn") && (theHiddenCell != null)){ var newValue = theCell.getValue(); if ((newValue != null) && (newValue != "") && (theHiddenCell.getValue() != newValue){ theHiddenCell.setValue(newValue); theCell.setValue(""); // clear the cell contents } }}
} }}
The only downside is that the cell doesn't show bullets for the cells that have been already edited (if you click on another control), but at this point that's not an issue for us. The main thing is that it shows the bullets while typing the password.
Thanks again!
I advise being very careful with showing passwords in a webpage, in this or any other fashion. In this scenario, any person who is even moderately savvy with JavaScript will be able to read your passwords by inspecting the CSOM of the grid, making them no longer secure even despite not being displayed throught he regular UI. Depending on the nature of these passwords, you may be opening up a very big security hole here.
My advice is to not use WebGrid for storing, displaying, or updating passwords, and to not render any passwords from the server to the client at all. Consider putting a WebTextEdit control outside your grid, used only for updating a password (never for displaying it, regardless of its PasswordMode property), and only on a page that uses HTTPS for added security. If you need to tie such input to data in a WebGrid, have the password set in the WebTextEdit apply only to the active row of the grid.
Oh, I see your point - so yes, after the textbox moves from edit to readonly mode, the cell is actually plain text (it is not WebTextEdit instance anymore - WebTextEdit is used for editing only).
So indeed - javascript may be the only solution here, I really do not see any other option.
Thanks for sharing the solution in public forums - much appreciated - I am sure many other people will find this useful.