Changes between Version 12 and Version 13 of MapGuideRfc20

Timestamp:

Oct 23, 2007, 3:30:54 PM (17 years ago)

Author:

trevorwekel

Comment:

--

MapGuideRfc20

@@ -32 +32 @@
 
 
-Expose the API:
+Add additional API to MgSite:
 
 {{{
- STRING MgUserInformation::GetUserName()
- MgByteReader* MgSite::EnumerateGroups( CREFSTRING user, CREFSTRING role )
- MgStringCollection* MgSite::EnumerateRoles( CREFSTRING user, CREFSTRING group )
+ STRING MgSite::GetUserForSession()
+ MgByteReader* MgSite::EnumerateGroups( CREFSTRING user )
+ MgStringCollection* MgSite::EnumerateRoles( CREFSTRING user )
 }}}
 
 Make the following internal changes:
 
-Append the userid (hex encoded) to the session identifier when it is created.  Modify permissions on !EnumerateGroups and !EnumerateRoles so that a user can enumerate his own groups and roles.
+Modify permissions on !EnumerateGroups and !EnumerateRoles so that a user can enumerate his own groups and roles.
 
 == Implications ==
 
-This RFC is strictly an API enhancement.  Having the userid contained in the session identifier makes !MapGuide a little less secure.  However, stealing a session identifier will compromise the user so the damage has already been done.
+This RFC is strictly an API enhancement.  !GetUserForSession exposes information already maintained by the !MapGuide Server.  !EnumerateGroups and !EnumerateRoles will be implemented using existing functionality.
+
+With the new API, hijacking a session identifier will allow access to the username, groups, and roles for a particular user.  Use of HTTPS will reduce the likelihood of session hijack for web sites requiring security.
 
 == Test Plan ==
 
-Write a simple app to verify that standard users can access their own groups and roles.  Also validate that non-Author and non-Admin users do not have access to other groups and roles.
+Write a simple app to verify that users can access their own groups and roles and cannot access information from other groups and roles.
 
 == Funding/Resources ==