Search options (Page 26 of 77)

Do you have your browser setup to pull the Atom/RSS feed from the forum? Just wondering if it might be due to the prev_url setup.

I think we may have crossed our wires then. If I understand correctly, your method would only allow access to those non-guest feeds when the user is actually logged in, regardless of whether it uses the cookie or not?

From what I understood of pedrotuga's initial post, however, (and I hope they will correct me if I'm wrong), is that it would use and extract info from the cookie to find the users g_id, if the user was not logged in, and decide on the feed contents accordingly.

Are you working on the basis of the feed only being available to the user when they are actually logged onto the forum, rather than extracting cookie info from the browser when the in-browser feed client updates the feed?

Always.

That cookie authentication part is a bit of a misnomer though. The cookie, in essence, doesn't mean diddley when the user isn't logged in. Plus, what's the point of a feed that you can only access once you're logged in? And if the auth mechanism contains some form of system whereby you don't have to be logged in to view it, then again, that comes back around to my original point. Security.

I'm quite willing to be corrected on my viewpoint if I've grabbed the totally wrong end of the cluestick, btw.

And it would also be the absolute worst nightmare of a Drac admin, if it was part of the core system, especially with such weak checks as those.

Do you have any idea of how many possible bugs or unexpected consequences a single item can have? That's the point of new releases. To incorporate new features when, AND ONLY WHEN, they have been fully designed, implemented and tested.

Stop being a drama queen. Something like the aforementioned setup has the ability to bollocks your restrictions the first time some muppet puts their feed link on a public system, and they will, without fail.

My apologies then.

TYPE is only relevant to the column, however. I think that mismatch in documentation is just due to documentation becoming more indepth. But saying that, I don't still run a 7.* DB, so can't attest to it with all certainty. (Unless I get one installed to test).

Looking at that patch, and assuming all you want to do is go from 15 to 39 for PgSQL, (and possibly set a default too), you should only need, (straight command line syntax, btw), :

ALTER TABLE [db prefix]posts ALTER COLUMN poster_ip TYPE VARCHAR(39);
ALTER TABLE [db prefix]posts ALTER COLUMN poster_ip SET DEFAULT '0.0.0.0';

Can't disagree with that.