Hi,
We're having trouble opening up the RSS feeds to unauthorized access. Currently, feeds are set to be open (Admin > System > Settings > Feeds > Basic Authentication set to Off), yet unauthorized access attempts result in a auth window popping up.
I've tested this on out-of-the-box CS and switching back-and-forth works fine. Will it require a restart of the app? Perhaps this is an issue with CSC 2.5.3 that's been fixed in later versions?
Walter
What is the jive.auth.disallowGuest system property set to on the instance?
Is there an SSO filter in place for the instance?
Hi Scott,
jive.auth.disallowGuest isn't set, though it probably should be, since unregistered access isn't allowed. Currently, redirects for unauthenticated users are handled by embedded code in the user-bar.ftl, which shouldn't be touched when viewing feeds.
There is an SSO in place which authenticates against a remote service based on cookies. Its functionality is additive: i.e., it doesn't replace the standard authentication, it merely adds to it. (The filter is inserted before the formAuthenticationFilter filter on the default filter chain.) It hasn't caused trouble to date, so it's not my first suspect.
Odd thing is, the behavior was as-expected as early as late last week. (Got it?) Christine Schmidt at ACS swears that it was working. She then tested it with RSS auth enabled, then set it back to disabled, which didn't get picked up. There haven't been any code changes for at least three weeks.
Walter
Can you provide the URL for the RSS feed that is having trouble so that I can test with it locally?
The problem is the permissioning of the Spaces.
The way the permissions are currently setup in the admin console, only registered users can view anything. The space permissions on the root community do not allow the "Anyone" user to view spaces or content within spaces. So, when the anonymous RSS feed request comes through, it tries to load up a community that cannot be viewed by a guest and the result is the auth request that is being seen.
To avoid this, the "Anyone" permissions line should have permission to view spaces and read content within the spaces. The jive.auth.disallowGuest system property will control whether non registered users will be forced to login to the instance or not.
Roger. I'll pass this on.
Thanks,
Walter
Let me see if I understand this....
If we give "anyone" access to view the space and to read the document and comments, then the feed works. They then click on a link and a Jive community page appears. Then because of SSO, they get redirected to the login page.
The one little wrinkle on this is a security pop-up box appears before the Jive page can fully render and redirect to the ACS login. I've attached a screenshot. I don't think this is too serious as they can't really capture this page or click on any links.
I believe the cause of that message is that there is a widget on that page that contains an image whose source comes from a URL that is not an https URL.
The widget is the one with the title "ES&T at the AGU Fall Meeting." At the bottom of that widget there is an image (that looks like text) that says "comments". This image is sourced from the URL http://feeds.wordpress.com/1.0/comments/estagu.wordpress.com/84/ which is not using SSL. Because the ACS site is using SSL, IE will give the warning you see if it loads something from a non-SSL URL in loading the page.
I understand the popup issue. The problem I was really concerned about was the redirecting from a Jive Page (which was not supposed to be accessible) back to the login page.
I think we're in the process of trying to fix/understand all that now.
Is this still happening? When I try to access the URL for the community in your example, I am immediately redirected to the login page without seeing the community page.
No. I think we are okay now.
C