Today I released version 2.4.7 of Gallery Server Pro. All versions have been updated, but the Web Application Gallery version takes a few days to get approved by Microsoft, so be patient for that one. There are no new features in this release; only bug fixes and one web.config change:
- Various functions do not work when viewStateEncryptionMode="Always"
- Case difference in username during logon causes duplicate user album
- Username not HTML encoded
- Exception data of inner exception not logged
- Possible NullReferenceException when gallery contains images with GPS metadata
- HTML embed code contains incorrect URL when the website is installed in a virtual directory
- Role name that contains HTML cannot be assigned to user
- Cannot add/remove roles for user when membership is read-only
- embed.aspx moved from web root to \gs\ directory
- web.config change: ViewStateEncryptionMode now set to “Always”
More details can be found in the Fixed Defect Report.
To upgrade from 2.4.6, download the 2.4.7 files to your hard drive. Then replace the GalleryServerPro.*.dll files in the bin directory with those from the download. Finally, replace the following files in your gallery with their matching file in the download:
- gs/embed.aspx (this is a new location; you may want to keep the original embed.aspx in the root directory if you have existing bits of embed code that point to this file)
If you are upgrading from a version earlier than 2.4.6, follow the instructions in the Admin Guide.
I’ll discuss a couple of the more interesting bugs.
Various functions do not work when viewStateEncryptionMode="Always"
I first learned about this issue from a user about a month ago. First, some background: One can specify that the view-state always be encrypted by setting a property in web.config:
<pages … viewStateEncryptionMode="Always">
When not specified, this setting is “Auto”, which means view-state is encrypted only when a control requests it. GSP works fine in “Auto” mode, but one of the third party controls it uses cannot handle the setting “Always”. This is the Callback control from ComponentArt, which is a nifty control I use for Ajax callbacks that is a nice balance between raw Ajax requests and the heavyweight UpdatePanel. When view-state is encrypted and the Callback control’s PostState property is set to “true”, this control fails with one of these messages:
“An error occurred while communicating with the server. Try again. Error: Invalid response from server.”
“The data could not be loaded.”
This issue affected the following functions in GSP:
- Album thumbnail paging
- Adding/editing a user on the Manage Users page
- Adding/editing a role on the Manage Roles page
While this problem has always existed, it hasn’t appeared on my radar until a few weeks ago. This is because version 5.6.1 of DotNetNuke, released January 19, 2011, started using “Always” as its default setting. DotNetNuke didn’t announce the change ahead of time because they didn’t think it would be a breaking change for anyone. But this was a big problem for GSP.
I contacted ComponentArt and they were responsive in evaluating the issue, but in the end they couldn’t provide a fix, acceptable workaround, or estimated date for a fix. So I replaced the album thumbnail paging with a traditional hyperlink architecture, where navigating to the next and previous pages is done with hyperlinks. And I re-architected the user and role management pages to use Microsoft’s UpdatePanel. In the end the changes should be largely invisible to end users.
To keep the settings consistent between the various flavors of GSP, the web.config of all versions now set this setting to “Always”. There is a small performance impact of this change (about 1-2%), so if you don’t need this extra security and want the fastest possible gallery, feel free to change this back to “Auto”.
Cannot add/remove roles for user when membership is read-only
One of the great features of Gallery Server Pro is its ability to use Active Directory integration for membership. This can be easily achieved through a few simple edits to web.config (see the Admin Guide for step by step directions). However, there has always been a limitation where one can’t add or remove roles for a user when the web application doesn’t have permission to modify Active Directory data. The Admin Guide describes a few workarounds, but I finally got around to eliminating the limitation altogether.
When clicking the Save button for a user on the Manage Users page, the gallery does two things: (1) update the user properties in the membership provider (such as e-mail address, comment, or approval status), and (2) update the list of roles the member belongs to. Starting with 2.4.7, if there aren’t any changes to the user properties, then only the role membership is updated. That is, the gallery skips a call to the membership UpdateUser() method, thereby sidestepping the possibility of the membership provider throwing a permission error. Voila – you can now manage role membership for users even when using Active Directory in read-only mode.