SSI Viewable by guest.

Started by robrahn123, January 17, 2010, 11:25:28 AM

Previous topic - Next topic

robrahn123

Hello.  I am running SMF 2.0 RC2.  I built a front page with SSI.  My problem is that half of the boards in forum are subscription only.  I would like to have SSI display information from all boards even the ones that are blocked.  Displaying Recent Topics, Post and boards would not show actual post just a tesser.  This would encourage subscriptions.  Could you trick the SSI to think it is serving to a subsrcibed user.  Then when they click link the forum takes over.

Like:


user_orig = user
user = subscribed

run ssi

user = user_orig


Even the stings would help.  I will keep looking.
Thank You Todd

Kays

Hi, welcome to SMF. :)

Which function are you using?

The problem is that what can be viewed using SSI.php is dependant on board permissions. If Guest can view the board then it won't be displayed.

If at first you don't succeed, use a bigger hammer. If that fails, read the manual.
My Mods

robrahn123

#2
ssi_recentTopics
ssi_recentPosts
ssi_topBoards

Quote from: Kays on January 17, 2010, 11:59:17 AM
SSI.php is dependent on board permissions.

Hmmm...  I was thinking you could in front page change user to subscribed, serve the page, then change back to guest.  Then the forum permissions would think it was a subscribed user.  I did this with this with color before.

Thanks

Arantor

Unfortunately it isn't as simple as doing that, since all the queries are implicitly tied to having permissions in them.

You'd have to modify SSI.php which opens a potentially very nasty security issue.
Holder of controversial views, all of which my own.


spartacussing

Arantor, I noticed in the SSI code, or maybe it was in the setup file... some code that indicated that you could specify what user to 'be' when SSI is running for the purpose of some queries?

If not, you could probably save the current user context, change it to an admin level user id, then switch it back when you are done

check out this post..
Quotehttp://www.simplemachines.org/community/index.php?topic=195524.msg1244958#msg1244958
booooo hoooo!

Arantor

First up, that code is an ugly, ugly hack. Second up, it's *specifically* for dealing with making a post as another user (why do that, when createPost will handle it all for you)

While, yes, you could in theory modify the running state in $user_info, it's really not recommended as it could have unforseen consequences. Better to make duplicates of the function(s) you want to use and modify those to not have restrictions.
Holder of controversial views, all of which my own.


spartacussing

... Yes, I wouldnt use it for creating a post or anything, but I fail to see how dire it would be (unforseen consequences and all that) for wrapping a clause that only reads from the database ( I think)

of course, even a simple 'read' probably does a lot of writes, updating time spent in the forum, history of read/un read posts among other things, so I suppose there may be ramifications of things not being what you expect, but I really dont see where we have any alternative(s).

The designers of this software made a LOT of assumptions, I'm not in their shoes so I cant speak ill or fair of their choices (though some are truly perplexing :p) but what I DO know , and I speak only for myself, that I just dont have the years invested in this as you guys have - modding a copy of some function (which I do not yet know) is just not appealing to me. Much as I would like to be expert and know all the innards of SMF , I dare not try as that would not be time well spent.
booooo hoooo!

Arantor

That's kind of the point - it may not always be just reading from the database. In theory that's all it should be doing, except that it isn't just as simple as that, because SSI still does things like session management.

Seriously, taking a copy of one function and altering the WHERE is simpler than trying to avoid the ramifications of screwing with $user_info.

So, you want to modify those three functions. What board(s) do you want to include/exclude from them? (I take it private moderation boards would likely still be excluded?)
Holder of controversial views, all of which my own.


spartacussing

yes, (private moderation boards and boards relegated for admin usage) but that wouldnt have to be "specified" per se, since I would expect to pass the function a list of boards to explicitly include.

Like the OP, I would like to have a "Teaser list" of references to content that is not otherwise accessible..

I am re-reading your position, and it does have me a little bit more wary: I cant guarantee that ALL internal routines would identify user context by looking at the USER array, they may get it from a query, in which case they would be very confused to say the least! - such an error (if one is raised, vs the database being porked, silently) may be difficult to debug.... I dunno...

Another option I was thinking of would be to simply Read directly from the database and be done with it... If I put this behavior completely in a function then at least its all in one place.. It's just that the SSI_topics is sooooo close to exactly what I want (except for the user context thing,lol)

oh well, I guess thats why they pay us the big bucks!
booooo hoooo!

Arantor

That's why I'm suggesting taking a copy of SSI_recentTopics and modifying it out to not call upon the $user_info, and instead listing the board or boards that are applicable (or if it's all of them less a few, an exclusion list)

I'm willing to show you the changes made if you can tell me what boards should be considered/excluded.

* Arantor is also contemplating doing something similar for SSI_recentPosts and SSI_recentTopics as he did for SSI_boardNews.
Holder of controversial views, all of which my own.


spartacussing

QuoteI'm willing to show you the changes made if you can tell me what boards should be considered/excluded
?
should that be necessary?

1. The include/exclude functionality is already there - all we want to do is disable or bypass the built in filtering based on user level?

..or am I missing something
booooo hoooo!

Arantor

Yes, it is already there, built into the queries, in fact. Guests only see what guests would be able to see. Regular users can see all the things regular users can see, admins can see everything.

So going back to what I said several posts back, some boards you'd want to be hiding, so what board or boards should be considered for the purposes of displaying recent posts?
Holder of controversial views, all of which my own.


spartacussing

it would be board 1,11,22,14

..basically an arbitrary list of boards (depending on profile)
booooo hoooo!

Arantor

And what profile options are there?
Holder of controversial views, all of which my own.


spartacussing

ok... It is an auto enthusiast board. This means that there will be discussion areas relevant only to aficionados of a particular auto type ( say Jaguar) as well more generic areas that all would partake in ( as well as premium areas that are specific and generic)

so therefore, establishing who the user is and what group they belong to, I then build a list of boards to display to pass to the board news function. My only problem was being able to extract information from the board(s) when the user doesnt have rights to see them.

After taking a cursor scan through the code, I've decided that the most efficient method is to temporarily set the user context before the call and reset it immediately afterward. It works, no hidden consequences, and I'm done! :D

The one thing I did differently, based on this discussion, was to make sure that the user that "reads the forum for SSI" was a REAL user, an admin user, but not one that is ever logged in (maybe a worthless precaution, but cost nothing to do.)

I'm really  not sure where you were going with that 'profile options' bit -maybe you're thinking of something else? :p

anyway, THAT's sorted, all I have to figure out now is easily getting the 'who's online list to take parameters... I think I have it, then, to simply add menu items to the main menu... I think there's a mod...lets see!

booooo hoooo!

Arantor

You said "depending on profile", so I wondered what the choices were.

The thing I think you may be missing - SSI functions look at the *currently logged in user*. If it's dependent on who that is, it will pull from the boards those users can see. I don't really see the point of pulling a list of most recent posts, for example, from boards they can't see...

What parameters do you want to push to the who's online list?
Holder of controversial views, all of which my own.


spartacussing

QuoteI don't really see the point of pulling a list of most recent posts, for example, from boards they can't see...

Ok, look at it this way.

Well, we wont display EVERYTHING from the posts - just show enough to whet the appetite. The point I am making, there is more to participation than ON/OFF

That is why, on my forums, Guests can post (in limited areas) , non members can browse the forums and sometimes post. Posts made by guests or lower level members after the first 5 minutes of posting, are only visible on hover/click, so naturally, if you want your stuff promoted, you register.

If you know that there is another community (but you cannot yet participate fully in it) you may want to adopt the behaviors that get you into that part of the site!

(which may mean paying, subscribing etc.)

In other words, there is always some other level up to achieve or be a part of.
keep walls around your little areas, yes, but sometimes, make peep holes for people to look through, and entice them :D
booooo hoooo!

Arantor

OK, so we're pulling titles and so on. Which brings me back to my previous question. When would you be displaying from all boards, and when would you pull from specific boards?
Holder of controversial views, all of which my own.


Advertisement: