Hi!

Here I'd like to share with DNN team some recent experiences of mine in customizing DNN Community 5.0.1.
I wanted to wire up membership data from my already existing database, and the Provider Model seemed to be exactly what I needed. This is a great thing to separate pure portal-related data from what can be considered part of the business application (users, roles etc.)! However, the implementation seems to have some flaws.

1. Most of the portal-related tables are decoupled from membership tables (no foreign key constraints) and this is fine, but there are still some which aren't. Example: Profile-table, which (as I understood) is supposed to store user-specific portal settings.
2. Some parts of Portal data provider (DotNetNuke.Data.SqlDataProvider) access data from other domains directly. This makes the whole interchangeability of single providers just impossible. Example: vw_TabPermissions uses Roles-table, but access to Roles should be managed by the appropriate membership provider.

Now a few words about permissions.
After I got problems with making DNN work with my membership providers, I stumbled across the code which is checking permissions and was slightly confused. In particular, about the methods "PermissionController.BuildPermissions" and "PortalSecurity.IsInRoles".

First of all, I wonder why the list of roles must be converted to string and then parsed again, instead of leaving it as a collection of objects. A meaningless thing to me and besides seems to have bad side effects. I didn't test it, but from studying the code I would suggest that usage of ";" and "!" in role names would result in wrong behaviour...
Secondly, I can't see the point of using role names instead of role ids for permission check. In combination with the deficient isolation of portal and membership data, mentioned earlier, that was exactly the problem I got after switching to my own provider: vw_TabPermissions returned null as role names (because standard Roles-table were not in use) and compared them to user's role names... With Ids everything could be much easier.

Hope this will help.

Stas,

thank you for your points of view. Please be informed, that roles are no longer separated into a provider, there is Membership provider only. There are a number of ideas for enhancements of users, membership and roles, but this is a question of resources available. This includes storing RoleIDs instead of Rolenames as well.

---

Cheers from Germany,
Sebastian Leupold

   

Speed up your DNN Websites with TurboDNN

[THIS SOMEHOW GOT POSTED TO THE WRONG THREAD, PLEASE IGNORE OR DELETE FROM HERE IF YOU HAVE THE POWER]

I'm looking for a simple solution for this as well. Document Exchange seems WAY to heavy for this. I know I can use DNN's secure folder stuff for a piece of this and can use the FileLinks.aspx functionality for another piece (as per Mitchell's blog, http://www.mitchelsellers.com/blogs/a...) But the missing piece is an easy way for my clients to get the links that they can then send to their clients.

Ventrian's File Links module makes it easy to grab the link but when an unauthenticated user goes to the link, they get a 404 error. It'd be much more ideal if this took them to a login page with a redirect back to the download after successful login.

---

David O'Leary
Efficion Consulting