[Private Community] Redirect on non-HTML output formats

judgej

I've raised this as a bug a while ago, but not heard anything so not sure if it was raised in the right place (probably core, is my guess).

Basically, when a user is not logged in, they get redirected to the interactive login page (whether that is internal to Vanilla or external if ProxyConnect is installed). That is fine if it is a user trying to access the application, but that is not always the case.

Other applications may try to fetch data from RSS feeds, or expect the results as JSON or XML data. Redirecting to a HTML page that requires input from a user is not going to be helpful at all.

For my purposes I have hacked the core to bypass this "private community" check if the requested data is RSS, because I wish to feed some of the latest posts to an external application. When a user follows the RSS links, then they get the login redirect and need to log in to see more information.

I expect there are other needs that surround how to handle non-HTML access to a private community when not logged in, but as a minimum, it needs an authentication error returned in the right format, and not just a blind redirect to the user-based login page.

TiGR

IMHO, allowing anonymous access to ANY part of private community is wrong. When something is marked as "private community", no one else should be able to read it. But if there is a way, then it's not private.

judgej

I get what you are saying, but it does kind of miss the point. I am talking about other applications accessing the forum, not people (that is why I am saying the redirect to the login page is wrong). How I protect the machine access (via IP address in my case) and how I protect what that machine sees from prying eyes, is outside the scope of this, but does not make the content of the discussion forums any less of a private community.

The fact is still that turning on "private community" kills all API access across the application because all AJAX, JSON etc. redirects to a HTML page, which is an API fault rather than the API telling the caller that it is not allowed access.

If this plugin returned an error in the appropriate format (to say "no anonymous access" or "the session has expired") then the remote application would be able to see that and call up another API with login credentials to perhaps get a session key (not sure if such an API exists?). At the very least it would return a status that the caller would recognise.