Blog Documentation Try Vanilla Cloud
Please upgrade here. These earlier versions are no longer being updated and have security issues.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Category RSS feeds all show "all discussions"

judgejjudgej ✭
in Vanilla 2.0 - 2.8

I'm using 2.0.13, which I know is old, but needs to live a little longer until we have time to upgrade it.

Now, we are finding, since moving to PHP5.4 from PHP5.3, that RSS feeds are acting a little funny. Each RSS feed that we use, points to a different category. However, the feeds we get back are the contents of "all discussions".

I have narrowed it down to a session problem. If there is no session cookie, then "all discussions" are returned. If there is a session cookie, then the correct category is returned. This happens the same whether fetching an RSS feed or viewing the normal HTML page in a browser with cookies turned off. The point is, our RSS feed reader does not have session cookies, so it is always given the wrong feed.

Does anybody here recall coming across anything like this on an older version of Vanilla? If so, any memory of what was causing it?

In the meantime I'll keep digging, but I'm not having much luck so far.

Comments

  • judgejjudgej ✭

    I guess in summary, until the browser supplies a session cookie, Vanilla 2.0.13 will deliver ALL categories on all category-filtered URLs.

  • hgtonighthgtonight ∞ · New Moderator

    I wish I could help, but I have no idea how to even start looking in to this with out a copy of the old version.

    Good luck!

    Search first

    Check out the Documentation! We are always looking for new content and pull requests.

    Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.

  • judgejjudgej ✭
    edited August 2013

    It is certainly a tough one to trace.

    When going to categories/foobar I can see the query being analysed and the category being added to the "p" parameter before the dispatcher. But then by the time it gets to the dispatcher, those details have gone and the "discussions" rather than "categories" controller is dispatched...

    ...but, only when there is no session cookie on that page. My only thought is that perhaps the permission checks are failing on the categories because it cannot check permissions before it knows who the user is (even if the user is anonymous), but I just cannot see in the chain of execution where this could be happening. Tearing my hair out :-(

    The URL says "categories/foobar", there is no session cookie, the foobar category is public, and yet "discussions/index" is despatched. As soon as I switch on the cookies in the browser, the categories controller is despatched instead, with the category passed in as a parameter.

    Sometimes I can grow to hate OO with so many layers with a passion :-(

    -- Jason

  • judgejjudgej ✭

    If in index.php I force a despatch:

    $Dispatcher->Dispatch('categories/foobar');

    Then that displays the correct categories page. With the dispatcher left to make its own way (the default in index.php):

    $Dispatcher->Dispatch();

    It falls back to 'discussions' when there is no session.

  • judgejjudgej ✭

    Wow - found it.

    It was the ProxyConnect plugin causing this. ProxyConnect attempts to authenticate against the remote authentication site at least once on each new session. If it fails to authenticate, then it resets the request route back to 'discussions', i.e. the home page.

    Without a session cookie, the session does not yet exist, and the ProxyConnect authentication requires that the session already exists in order to work. I don't know if the bug I raised recently on the session handling was present back in 2.0.13 days, but if it was, then that would explain why the session was not working without the session cookie.

    The bug I raised involved setting session values. The way the session worked was that you could set a value in a session, but could not retrieve it again until the next page. Without session cookies, which is what I have here, there is never a "next page" for the session - everything has to work in one page request. Except it wasn't.

    This will probably also explain some other weird things I have had with ProxyConnect over the years. On creating a user, I was wanting to add some profile details to that user, such as a signature and project name. The problem is that these details would never stick on first creating the user, but would on subsequently logging in. Again, I think it is down to session values not being available once they are first created, but available only on the next page. That's a long term mystery solved for me, I think.

    Whether that will help anyone else or not, I don't know. All I did in ProxyConnect was to comment out the line that resets the route.

    -- Jason

  • judgejjudgej ✭

    Here is the site, if anyone is interested:

    http://www.localfoodgrants.org/

    Vanilla was a closed group behind the FoodECommunity->ProjectTalk tab for the last three years, but is now open to the public. Registrations are not open yet, but will be soon.

Sign In or Register to comment.