We need to give all our staff access to preview content in Rhythmyx via LDAP authentication, whether they are explicitly listed within a role or not.
We have had this working, in that users can view preview urls (NOT the action panel!) that have been mailed to them, but recently, some content has thrown errors complaining that the user is not in XXX community (which they aren’t, as they are not referenced anywhere in Rx). At other times (which we haven’t tied down) we get "The role list of the authenticated user XXX must not be empty… (error code 1,108) " - Obviously the role list is empty, as the “guest” user doesn’t have any roles.
I used the “flush cache” command in Server Admin, and now they consistently cannot access any preview content, even though they have authenticated with LDAP.
We had exactly the same problem on our dev server and using “flush cache” had the same effect on that server too.
Could anyone point to what settings are required to allow “Non-Rhythmyx” users who sign in to see content items in preview?
Our ACL Settings are for “Data Access” only against the default user and these haven’t changed recently, to my knowledge.
The baffling thing is that users could preview some content before I used flush cache and then immediately after using it, they get the errors above.
Any help would make my new year! (I might even post a few tips for using JSPs on 5.7).
If this works at all, it’s an accident. Rhythmyx was never designed to allow access without any roles at all.
The best thing you can do is set up a group role using some LDAP group that contains all of your users (which probably exists already in your directory). This should allow all users to access the system.
2). We’ve now added a “All_Content_Readers” role assigned this role to a global LDAP group in Server Administrator, and then added the role to the Community and we still get the “user XXX not in Community” error. Are we missing something obvious? (BTW, the “All_Content_Readers” role is also a reader assignee in all the workflow states)?
3). We needed to add another security provider in Server Admin to give us access to our “global” group. Strange thing is, existing users then couldn’t authenticate via LDAP. It seems to be the order the groups are listed in the security providers page because if we simply rename the provider from “All Users” to “ZAll Users”, we can authenticate! - it seems Rx is only looking at the first LDAP Security Provider. We are using the same directory set for both LDAP Providers - do we need separate directory sets for each LDAP provider?
4). The good news is we’ve tracked down the cause of the intermittent access. It appears that if someone with the appropriate access has accessed the content, it stays in the cache and is then accessible by anyone who logs in. Once you flush the cache you get the “not in Community error”. If a “proper” Rx user then previews the page, the “guest” user can once again access the preview content, so at least we have an explanation for that specific behaviour.
[QUOTE=Nigel;865]
1)Yes, it is a 5.7 system. Makes sense. Some of this is a little different in 6.x (you don’t need 2 providers, for example).
2). We’ve now added a “All_Content_Readers” role assigned this role to a global LDAP group in Server Administrator, and then added the role to the Community and we still get the “user XXX not in Community” error. Are we missing something obvious? (BTW, the “All_Content_Readers” role is also a reader assignee in all the workflow states)? In the server admin client, try setting the “sys_defaultCommunity” attribute for the All_Content_Readers role to the name of your community. I’m not sure that this will fix it, but it’s worth a try.
3). We needed to add another security provider in Server Admin to give us access to our “global” group. Strange thing is, existing users then couldn’t authenticate via LDAP. It seems to be the order the groups are listed in the security providers page because if we simply rename the provider from “All Users” to “ZAll Users”, we can authenticate! - it seems Rx is only looking at the first LDAP Security Provider. We are using the same directory set for both LDAP Providers - do we need separate directory sets for each LDAP provider? In 5.x, yes, you’ll need 2 separate directory sets. In 6.x, you should be able to use just one.
4). The good news is we’ve tracked down the cause of the intermittent access. It appears that if someone with the appropriate access has accessed the content, it stays in the cache and is then accessible by anyone who logs in. Once you flush the cache you get the “not in Community error”. If a “proper” Rx user then previews the page, the “guest” user can once again access the preview content, so at least we have an explanation for that specific behaviour. This makes sense, and it was my initial “guess” as to why it worked in the first place. This is another “hole” that we’ve plugged in 6.x