I’m happy to announce the release of mojoPortal 2.3.8.1, available now on our download page.
What’s New?
Security Updates
Stronger password hashing for hashed password format. Previously we were using MD5 without salt, but now we use sha512 with a random 128 character salt per user. Existing users will be automatically updated to the stronger hash the next time they login.
For encrypted passwords we’ve also updated to use a 128 character random salt per user. Existing users will be updated with a salt the next time they login.
In version 2.3.7.6 we changed the SSL behavior to keep users in a secure session once they sign in. After the release we noticed that the canonical url was using https for secure requests and http for insecure requests which could affect SEO since the canonical url should not vary. We’ve changed it in this release such that if the page does not require SSL and the site does not require SSL for all pages, then the canonical url will use http, otherwise it will use https. This way it will be consistent and not vary to make sure there is no inconsistency if search engines happen to crawl the pages using https.
When a user’s roles are changed, the role cookie will now be updated automatically on the next authenticated page request. Previously, if you added a user to a role or removed him from a role he needed to logout and login again to get the new role cookie.
Usability Improvements
We’ve made the role permissions more clear on Page Settings and Feature Instance Settings. There has been some confusion in the past about a special case of permissions. By default Administrators and Content Administrators can access and edit any content without adding them to the allowed roles, but we had a special case where if you set the allowed roles to only Administrators then the content could be locked down to only Administrators and Content Administrators would no longer have access. In the past this has not been an obvious feature from the UI and users who did not know about that feature would mistakenly check the box for Administrators, accidently locking out Content Administrators. We’ve now made it more clear in the UI with radio buttons above the role lists for Page and Content View and Edit Permissions like this:
Note that if you want to lock some content down so that only Administrators can access it, you should set both the page view/edit permissions and the feature instance view/edit permissions to Only Administrators. Otherwise if you only secure the page, Content Administrators can still access the content instance from Content Manager outside the context of the page security.
A related change is that now if you have more than 20 roles, by default we use separate pages for page and feature instance permissions, and the site level permissions have been moved out of the Site Settings page into their own pages. This was done because of a change in behavior in ASP.NET after a recent security update. Now if a page is using postback with more than 1000 form elements, it causes an error, and we moved these things to reduce the number of form elements on a page because if you have a lot of roles the checkboxes for each role for each permission adds up to a lot of form elements and combined with other form elements on the site settings page and hidden elements used for viewstate some users were getting errors when they would save site settings due to too many form elements. There is a workaround to allow more form elements but we wanted to make it work without doing that so it seemed like a better idea to reduce the number of form elements by not having as many things all on one page. We also did some viewstate optimization to reduce un-needed viewstate in some features.
We also added paging to the /Admin/SecurityRoles.aspx page which shows the users for a given role, and we made the feature instance settings page use the same skin as the page when using page specific skins.
Blog Improvements
The blog now shows the post categories for a post in the post list and in the post detail. We’ve also implemented more of the Wordpress API, so in addition to being able to use Windows Live Writer, it is also now possible to use Wordpress clients such as the Blogsy app for iPad. I’ll be documenting that soon but basically you configure it as if you were using Wordpress.
Html Content Improvements
Several people have reported problems when trying to use javascript in the Html Content Feature, the WYSIWYG editors such as CKeditor and TinyMCE tend to do some “cleanup” on the markup which sometimes removed things that people intended to be there. In CKeditor for example you could get around it by saving while still in Html view, but the next time you opened the content in the editor it would run the “cleanup” and mess up your javascript. For content instances where you are using javascript and just want to edit the raw html without interferance from the WYSIWYG editor, you can go into the settings and un-check the box for “Use WYSIWYG Editor?”, and then it will just use a plain text area when you go to edit that content instance.
Most Additional Language Resource Files are Now In a Separate Download
As the number of translations and partial translations of resource files has grown over time, it has added to the size of the download, but more importantly it has increased the amount of time it takes for the ASP.NET compiler to compile the files for the initial request when a site is first started up, or the application pool is recycled such as when deploying an upgrade. Each of those .resx files is compiled by the ASP.NET compiler and over time as we have got so many of them it has become too much and it adds significant time to the initial site startup. So we now have a separate languagepack.zip that has the additional languages. You can copy the language resource files you need from there into your /App_GlobalResources folder. For those upgrading, you may already have a lot of existing resource files in that folder that you don’t need. My advice would be to delete the languages you are not supporting in your site from the /App_GlobalResources folder just before upgrading. Do not delete the English resource files though because those are needed for fallback when other languages have missing keys. The English files are named without a language code like Resource.resx and BlogResources.resx whereas other languages have a language code like Resource.ru.resx and BlogResources.ru.resx for Russian. The main package now only contains the resource files for English and Italian and the other languages are all in the languagepack.zip
WebStore Improvements
The way payment gateways was plugged in in the past for card processing gateways like Authorize.NET and PlugNPay was kind of a mess, it is now a true provider model so that new gateways can be implemented in separate assemblies (dlls) and plugged in by configuration, so it should be easier now to implement new gateways. I’ll be documenting this soon. It doesn’t affect PayPal or Google Checkout because those are special cases where we don’t process the credit card payment on our own site, it happens at the PayPal or Google Checkout site and those payment gateways can be used in addition to a standard card processing gateway where the user doesn’t leave your site to complete the transaction. The new provider model is only for standard card processing gateways.
There was also some redundancy with the old way we implemented Authorize.NET and PlugNPay, they each had their own separate log for logging transactions which was redundant and would have only become worse if we kept adding new logs for each new payment gateway, so we now have a consolidated payment log used by all standard card processing gateways (ie ones that implement IPaymentGateway provider). The upgrade script will migrate existing data form the old Authorize.NET and PlugNPay Logs. Since our add on features Web Invoice Pro and Event Calendar Pro also use the payment gateways, we have corresponding upgrades of those features and you should upgrade them at the same time as you upgrade mojoPortal to make sure that going forward new transactions are being logged in the new common payment log (Note that this really only matters if you’ve been using Authorize.NET in those add on products).
In WebStore it is now also possible to move an order from one site user to another one on the AdminOrderDetail.aspx page. I’ve needed to do this in the past when the user who completed the order no longer works at the company that purchased a product so a different user needed to be able to get the product updates.
Miscellaneous
The Feed Manager now supports relative urls for use with internal feeds using the ~/ syntax to represent the site root.
When using Folder based child sites with related sites mode, closing the master site now closes all the sites
FCKEditor has been removed and is no longer included with mojoPortal because it is no longer kept up to date and doesn’t work well with newer browsers. CKeditor is the new generation of FCKeditor and we’ve included both of them for quite a while. Note however, that if you are upgrading from an older version, the FCKeditor files are still on disk from previouse installation, we are not deleting files during upgrades, so if you really wanted to keep using FCKeditor you could re-enable it by using a custom configuration file to plug in FCKeditor. But, my advice is don't use it, it has problems in newer browsers like IE 9 anyway and CKEditor is a better product.
Fixed a bug where the Janrain Engage sign in system wasn’t working correctly when using multiple sites with related sites mode, we’ve also updated to the newer Janrain Engage widget code.
Fixed some issues with theme caching where it wasn’t always loading the correct theme.skin file when using page specific skins.
Fixed a problem where the SiteRoot was being cached as a property on SiteSettings and then used in various places to build urls. The problem was that if you were accessing the site with more than one url such as using a domain name and by ip address, the cached site root might not be correct for the context of a specific request. This property has now been deprecated and all places in mojoPortal where we were using it are now using SiteUtils.GetNavigationSiteRoot() to make sure the site root is calculated in the context of the current request.