Restricted access bugs in Dreamweaver

First, the steps described:

1, the database file Mysite.mdb, of which two tables: Admininfo (representing the Administrator's record table) and MemberInfo (ordinary user's record table)

2, ordinary user landing page Login.asp, add server behavior, select based on user name and password access. This means that the session ("Mm_username") is generated (the value is the username that is currently correctly logged in). Because the access level is selected at this time, the session ("Mm_userauthorization") that represents the access level = ""

3, the normal User Landing Success page personal.asp, server behavior "limit to page access" also set to user name and password access. The essence is to judge the session, you can achieve "Restrict access to the page."

The above 2→3 can be normal, then began to appear problems.

4. Admin login Page adminlogin.asp, when adding server behavior, select access based on user name, password, and access level (this requires, of course, that the Admininfo table must have a field that represents the access level). Generates session ("Mm_username") (the value is the name of the administrator that is currently correctly logged in) while generating a session ("Mm_userauthorization") that represents the access level = CSTR (mm_ RsUser.Fields.Item (mm_flduserauthorization). Value)

5, the Administrator log on the correct page admin.asp, it is obvious that the server behavior "Restrict access to pages" must select "User name, password and access rights", the definition value of the level is the value of the Admininfo table that represents the access level field. You can also implement "Restrict access to pages."

Second, the bug came

1, the ordinary user login.
2, the correct landing.
3, the URL address directly switch to "admin.asp" address.
4, fully accessible.

Note: The Admin.asp extraction session ("Mm_userauthorization") is a null value, and when correctly logged from adminlogin.asp to adming.asp extract session ("Mm_ Userauthorization ") value is the value of the corresponding field in the database table

Conclusion: The level of access that represents the privilege is not effective. Session ("Mm_userauthorization") for the same site the same database different tables-the same as a fake!

Three, principle analysis

In the Admin Login Success page, the following code is used to "Restrict page access"

' * * * Restrict access to page:grant or deny access to this Page
mm_authorizedusers= "the Administrator"
Mm_authfailedurl= "Adminlogin.asp"
Mm_grantaccess=false
If session ("Mm_username") <> "Then"
If (False Or CStr (session ("Mm_userauthorization")) = "") or _
(InStr (1,mm_authorizedusers,session ("Mm_userauthorization")) >=1) Then
Mm_grantaccess = True
End If
End If

If session ("Mm_username") <> "Then"

If the user's session is not empty, Mm_grantaccess = True, and of course, there are nested IF.

If (False Or CStr (session ("Mm_userauthorization")) = "") Or (InStr (1,mm_authorizedusers,session ("Mm_userauthorization )) Then >=1)

Because mm_authorizedusers= "Administrator", the "administrator" here is the level defined value, that is, the value of the access level field represented in the Admininfo table

Therefore, it can restrict access to administrators of other access levels (not administrator) of the Admininfo table, while for ordinary members, its session ("Mm_userauthorization") value is null, and the permission page is also accessible.

This is where the bug is!

Iv. Current Solutions

1, to do based on user name, password and access level, must be in the same database table. The information about ordinary members and administrators is saved in the same table, and the way to distinguish them is to add a field that represents the permissions so that they have different values.

Of course, this is not very complete, many situations need to separate two tables, then you can use the following methods:

2, when based on user name, password and access level of access, in the code

If session

("Mm_username") <> "Then

Continue adding content

and session ("Mm_userauthorization") <> "", which is the last:

If session ("Mm_username") <> "" and session

("Mm_userauthorization") <> "Then

Note: When accessed based on user name, password, and access level, it is possible to modify (because there is an access level, the session ("Mm_userauthorization") is represented), and it is not necessary to be based on user name and access.

V. FINAL RECOMMENDATIONS

Of course, this recommendation is best for the MM company, that is: when based on user name, password and access levels, the code determines the line and when access based on user name and, otherwise, should be:

If session ("Mm_username") <> "" and session

("Mm_userauthorization") <> "Then