Community Support Forums

Re: Possible BuddyPress conflict

2011-12-30T22:00:40-05:00

Jason that did it! You rock! Thank you soo much.

Statistics: Posted by kamalski — December 30th, 2011, 10:00 pm

Re: Possible BuddyPress conflict

2011-12-30T21:36:46-05:00

Can I see your WordPress Permalink settings too please?
You might try changing your URI Restrictions to:

Code:: /members /groups /activity /blogs

Statistics: Posted by Jason Caldwell — December 30th, 2011, 9:36 pm

Re: Possible BuddyPress conflict

2011-12-30T05:05:10-05:00

Thanks for the quick reply Cristian

Screenshot:

links:
http://audyolab.com/activity
http://audyolab.com/courses
http://audyolab.com/main-forum
http://audyolab.com/blog

Statistics: Posted by kamalski — December 30th, 2011, 5:05 am

Re: Possible BuddyPress conflict

2011-12-30T04:53:18-05:00

Could you post a screenshot of your URI restriction? WP Admin -> s2Member -> Restriction Options -> URI

And also a link to the URLs you're trying to restrict but are not being restricted?

Thanks!

Statistics: Posted by Cristián Lávaque — December 30th, 2011, 4:53 am

Re: Possible BuddyPress conflict

2011-12-30T04:24:19-05:00

Am having a similar issue, where certain buddypress pages are accessible even if the user isn't logged on.
The activity, groups and forum pages are all accessible.

I have setup Level #1 page restrictions to all buddypress pages and URI restrictions to all buddypress URI's, however they are still accessible.

The activity, groups and forum pages are all accessible, except the members page which is protected by the URI restriction

Thanks,
Kamal

Statistics: Posted by kamalski — December 30th, 2011, 4:24 am

Re: Possible BuddyPress conflict

2011-12-20T14:29:31-05:00

Thank you for finding it and helping us improve s2Member.

Statistics: Posted by Cristián Lávaque — December 20th, 2011, 2:29 pm

Re: Possible BuddyPress conflict

2011-12-20T10:32:40-05:00

Thank you.

Statistics: Posted by jmdodd — December 20th, 2011, 10:32 am

Re: Possible BuddyPress conflict

2011-12-20T09:23:34-05:00

Investigation completed. This will be corrected in the release of s2Member v111220 later today.

= Changelog excerpt for coming release of v111220 =
* (s2Member Pro) **Security hardening**. s2Member's Systematics routine hardended against a possible attack coming from a spoofed IP address matching that of the installation server itself. For further details, please see [this thread](http://www.primothemes.com/forums/viewtopic.php?f=4&t=16412&p=57044#p57044).

Statistics: Posted by Jason Caldwell — December 20th, 2011, 9:23 am

Re: Possible BuddyPress conflict

2011-12-20T09:12:59-05:00

Thanks for the heads up on this thread.

This sounds like an issue related to s2Member's localhost detection. I'm investigating this now, to see if we can tighten security in this regard. The server itself triggers s2Member's Systematics routine, because the server is accessing itself from the same IP address via lynx ( to be expected ). However, security should be tightened in this regard, because IP addresses can be spoofed by an attacker.

Statistics: Posted by Jason Caldwell — December 20th, 2011, 9:12 am

Re: Possible BuddyPress conflict

2011-12-20T07:45:11-05:00

The following page is protected by ID: http://example.com/help/where
I cannot browse it with Chrome; but if I log into the server and type 'lynx http://example.com/help/where', it looks as it would if I were logged in as at least s2member_level1.

The following URL is protected by URI: http://example.com/forums
Same as above. Logged into server browsing on the command line, I can see the content; browsing conventionally, content is protected.

When I did this, I was not logged in via Lynx's cookies. What is interesting is that the menu above the content is the one that we show not-logged-in users.

Code:: if ( current_user_can( 'access_s2member_level1' ) ) { wp_nav_menu( array( 'container' => false, 'menu_id' => 'menu-blog-dropdown', 'theme_location' => 'member', 'fallback_cb' => 'bp_dtheme_main_nav' ) ); echo 'member'; } elseif ( current_user_can( 'subscriber' ) ) { wp_nav_menu( array( 'container' => false, 'menu_id' => 'menu-blog-dropdown', 'theme_location' => 'subscriber', 'fallback_cb' => 'bp_dtheme_main_nav' ) ); echo 'subscriber'; } else { wp_nav_menu( array( 'container' => false, 'menu_id' => 'menu-blog-dropdown', 'theme_location' => 'nonmember', 'fallback_cb' => 'bp_dtheme_main_nav' ) ); echo 'nonmember'; }

I added a simple echo statement to the wp_nav_menu logic and it printed out 'nonmember' as being the condition that was true when I was logged into the server and using Lynx. (When logged into the site via Chrome, 'member', when logged out via Chrome, 'nonmember', which is the correct behavior.) In Lynx, the login user/password box, not the logged in user message, also appears in the sidebar.

The site is on a dedicated private server, and there are no other accounts or sites on the server.

Statistics: Posted by jmdodd — December 20th, 2011, 7:45 am

Re: Possible BuddyPress conflict

2011-12-20T05:15:50-05:00

Ah ok, I think I understand now. I'll email Jason about it.

Tell me, do you see this happen with the URI restricted content or also with the Page restrictions?

And were you logged out of your account when you browsed them? Just making sure.

Would this be a restriction problem if you could only do it while logged in to the server? Can others do that?

Statistics: Posted by Cristián Lávaque — December 20th, 2011, 5:15 am

Re: Possible BuddyPress conflict

2011-12-19T23:51:43-05:00

That is correct. Using Chrome/Safari/Firefox, the site behaves as it should -- protected content is protected. We've set up the site using mainly URI (for BuddyPress) and Page/Post restrictions by ID.

When I am logged into the server itself and I use Lynx or telnet or wget to the complete URL on the command line, I get the protected content delivered and can browse the entire site using Lynx. I verified this with our server admin, but we were unable to replicate the results from an external box.

Statistics: Posted by jmdodd — December 19th, 2011, 11:51 pm

Re: Possible BuddyPress conflict

2011-12-19T23:09:05-05:00

OK.

Let me see if I understand: if you load the protected page with Firefox or Internet Explorer, you get the 301, but if you load the same pages with Telnet or Lynx you get the content you shouldn't get. Is that correct?

Regarding the localhost, is that your local machine? If so, make sure you check out this setting WP Admin -> s2Member -> General Options -> Localhost

Got it on the URL flickr going to the Membership Options, that's good.

Statistics: Posted by Cristián Lávaque — December 19th, 2011, 11:09 pm

Re: Possible BuddyPress conflict

2011-12-19T09:34:42-05:00

Testing on the same server with Telnet or lynx does not produce a 301 response, but the protected page content. On all other servers I've tried from, I get a 301. When I tested the site briefly this weekend for usability, I did it from the same server's command line.

I just want to make sure that this is a localhost/Apache configuration issue, not one in which a spider will be able to read the site. I'm also checking this behavior with server support.

(And yes, the URL flicker does send the user through to the Membership Options page.)

Statistics: Posted by jmdodd — December 19th, 2011, 9:34 am

Re: Possible BuddyPress conflict

2011-12-19T05:06:57-05:00

I'm not sure I understand. You mean the URI restriction is not preventing a non-logged in visitor to view a page that is restricted at Level 1?

And regarding the URL flickr, that may be WordPress finding a post that may match the URL you entered. But then the user doesn't get the page and is instead sent to the Membership Options page, right?

Statistics: Posted by Cristián Lávaque — December 19th, 2011, 5:06 am

Possible BuddyPress conflict

2011-12-17T17:28:45-05:00

Using a regular browser, the site is protected and behaves as it should. (The general public and anyone whose membership has not been moved to s2member_level1 can only see a limited set of pages.) However, when someone who is not logged in tries to go to http://site.com/foobar, and there is a WP post called foobar-esque, I see the browser location briefly flicker with a http://site.com/foobar-esque, then it forwards to the membership page.

The site is running up-to-date versions of WordPress, BuddyPress, BBPress, and s2Member. When I disabled all other plugins and returned to the default BP theme, the problem persisted. There is no inline content protection, only that provided by Restriction Options. Page and post ids are at Member Level 1, with the suggested BuddyPress URI restrictions also at Member Level 1.

When I am not logged in, there is still a way to view the entire site as if I were a logged-in user. Is this a normal behavior, and do I need to add inline content protection to all of the site templates?

Statistics: Posted by jmdodd — December 17th, 2011, 5:28 pm