Security Assist - Minor Bugs and or Annoyances

Hello,

As I am using the new Security Assist v2 (contained in Data Bridge) for the first time, here is a list of a few things that I have noticed:

-No "Forgot Password" link on the login pages.

This pretty much says it all, if you create a Forgot Password page with the wizzard, should a forgot password link not automagically be added to the login page?

-"NodeToOffsets" Error when changing permissions?

I changed permissions to the registration page so that it was only available through the backend system and ther error in the attached image was spat out while it was being updated. Once you click OK then the wizzard is frozed and doesn't go any further.

====================================

Please let me know if these are slated for fix in the next release, thank you.

I will add more if I find anything of note.

It should be noted that the NodeToOffsets error happens any time I attempt to add a "logged in" permission to the user registration page.

More annoyances/bugs:

-Passwords MUST be entered on user update pages.

User update pages contain the Password fields, and they are both required to fill out that form. As such you need to enter the password for a user even if you leave the field blank.

Is it not standard practice to have the field do nothing if left blank and if the fields are filled then the new password would be entered into the database?

-No 'Cancel' button in either Registration or Update pages

As stated, no cancel button to take you back to where you were.

Anyone from WA have any input on this?

-No "Forgot Password" link on the login pages.

I have logged this in our system. In the mean time you can easily add a link to the forgot password page:

<a href="forgotpassword.php">Forgot your password?</a>

-"NodeToOffsets" Error when changing permissions?
I have not been able to reproduce this issue. Are you using the access pages manager? or using the page access server behavior?

What is your OS?

What version of Dreamweaver are you using?

If you are using the access pages manager, make sure that the registration is not open in dreamweaver before applying the page restriction.


-Passwords MUST be entered on user update pages:

on the user update pages, the password and confirm password form elements should be set so that the initial value is coming from the users recordset like all of the other elements on the update page. this way the original password will be remembered.


-No 'Cancel' button in either Registration or Update pages

I have logged a feature request for this, in the meantime, you can easily add a cancel button:

<input type="button" value="Cancel" onclick="history.back()">

Originally Said By: Jason Byrnes

  -"NodeToOffsets" Error when changing permissions?
I have not been able to reproduce this issue. Are you using the access pages manager? or using the page access server behavior?

What is your OS?

What version of Dreamweaver are you using?

If you are using the access pages manager, make sure that the registration is not open in dreamweaver before applying the page restriction.


-Passwords MUST be entered on user update pages:

on the user update pages, the password and confirm password form elements should be set so that the initial value is coming from the users recordset like all of the other elements on the update page. this way the original password will be remembered.  

-NodeToOffsets Error:

This happens when the Page Access Manager is opened at the end of the creation of these pages. Thus the wizzard has left the file open - this therefore is a bug in how this all works. Not to mention that the Page Access manager opens the file in question in order to add the code (this does work succesfully in this manner however.) Seems like an odd bug to me as the end user.

-Passwords

When using encryption it takes a pile more code for me as the end user to get the password to remain. I have to determine if it is the same hashed code, otherwise the hashed code will get rehashed. :) Is there really no way to make this more seamless for us, so that we can avoid needing to add a whole pile of other code?

-NodeToOffsets Error:
OK, I see, that was not clear from the original report, the devil is in the details. I still am not able to reproduce the problem when using the Access pages manager that opens after the wizard is complete.

What is your OS?

What version of Dreamweaver are you using?

-Passwords
this also was not clear from the original report that the pages where using encryption. i will log a bug that the user update page should ignore the password entry if left blank.

Sorry, OS is win7 x64 and DW 5.5

It wouldn't work either when the page was created initially, or when I went in a tried to add the restriction afterwards. It did however work when the page was closed after the fact as you suggested.

Let me know if you want to see it in action.

Thanks.

Originally Said By: Jason Byrnes

  -Passwords
this also was not clear from the original report that the pages where using encryption. i will log a bug that the user update page should ignore the password entry if left blank.  

I don't think that I would leave the passwords un-encrypted for any website that I make, especially when security is a concern. :)

hmm, i have tried reproducing the error using my windows 7 system, but cannot, I have created a support ticket so we can look into this issue further.

To view and edit your support ticket, please log into your support history:
supporthistory.php

If anyone else is experiencing this same issue, please append to this thread.

  I don't think that I would leave the passwords un-encrypted for any website that I make, especially when security is a concern.  

Then you must also make sure that the login and protected pages use SSL right?

I completely agree with encrypting passwords, but it really is only one part of the overall puzzle. I fear that most people relying on encryption are falling into a false sense of security.

encrypting the passwords in the database will only protect the users data if someone gains direct access to your database. In actual fact, this is a very rare occurrence.

A much more common problem is hackers that use packet sniffing to look at information being transferred through form posts that are not secured under an SSL layer.


the way that password encryption works is that the plain text password is posted to the server. The server then takes the plain text password and encrypts it. An SQL query is then performed using the username and encrypted password to see if a record exists in the users table.

unless the login form is protected under an SSL layer, the plain text password in the form post is vulnerable to network packet sniffing attacks.

Just something to think about, especially when security is a concern.