I am using drupal 6.17, og 6.x-2.1. I have NEVER used og_forums, and I have now disabled og_access control to see if that was generating the error.
Problem (User1 is admin of group, User2 is simply a member):
1. User1 is able to add group_post, no errors.
2. User 2 can see post.
3. When user 2 "creates group post" the post form appears, but in the log, the error below is generated.
4. When user 2 "submits" the post, the user sees "You must join a group before posting on this web site."
AND
5. An identical error is generated in log.
Error generated:
User User2
Location http://home.org/node/add/group-post?gids=gids%255B0%255D%3D1457
Referrer https://home.org/node/add/group-post?gids=gids%255B0%255D%3D1457
Message current() [function.current]: Passed variable is not an array or object in /home/home/public_html/sites/all/modules/og/og.module on line 579.
It appears that only admin level users (user1 is also User 1 in db) can actually post group content. I have seen old issues in this regard, but most related to og_forums. I have never used this module. I am not even sure how to debug. Help?
Maria
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | 861996-securepages-url_query_mishandling.patch | 669 bytes | mstef |
Comments
Comment #1
mariagwyn commentedEdit: It turns out that User1, when clicking "create group post" generates the same error. However, user1 is able to submit the post with success.
Comment #2
mariagwyn commentedI am using webchick's quick and dirty backtrace, and here is the error printed out on screen. Could it have anything to do with the very strange looking url in [2]:
[0] => gids%5B0%5D=1457. On other sites I run, this should look like this:gids[]=1457Here is most of the output (I eliminated some of the earlier calls). Any idea what might be causing this very odd url? Or does someone see a problem I am missing?
Thanks,
Maria
Comment #3
mariagwyn commentedAfter more testing, the problem is indeed in the URL. The link to "create group post" in the group block is correct. However, once it is clicked, this > "gids[]=1457" becomes "gids=gids%5B0%5D=1457". If I manually type in the correct url, everything is fine, no errors. I have disabled any module that rewrites paths (pathauto, path), nothing works. I tried to install older versions of OG (this is a recent problem), didn't work either.
What in the world is rewriting the URL?
Comment #4
mariagwyn commentedchange title to reflect problem. really need help on this one, I have disabled many modules, no affect.
Comment #5
mariagwyn commentedThis was posted under OG b/c I thought the error started there. However, after disabling all modules and re-enabling one by one, it is secure pages.
I had the following pages secured:
node/add*
node/*/edit
When I removed these from the secured area, the URL constructs fine. I have no problem keeping add/edit pages unsecured. However, this could be a more serious problem for others. It doesn't seem correct to have this: "gids[]=" become "gid=gids%5B0%5D=". Not only is "gids[]=" being doubled, but the second iteration explodes the [].
Comment #6
wrightnow commentedYou guessed it, this is a real problem for us. We're attempting to have all users who register through a given location automatically added to a group. Works fine without Secure Pages enabled, but with SP enabled, has the double link/explosion problem you outline. This is clearly a conflict/problem because probably the most important pages to have secured are those that deal with User registration...
We're working on a work-around/fix and I'll let you know if I find one - any suggestions would be appreciated. Following errors are reported, but they're asked and answered at this point.
Comment #7
jaarong commentedI'm having the same problem where the url is being garbled and error generated.
Comment #8
mstef commentedsubscribing
Comment #9
mstef commentedSee patch..
The problem lies inside securepages_get_query()
If the query is an array, http_build_query() was being used, then it was doing the normal encoding - but http_build_query handles that already. It is also passed the key, so re-adding it adds to the mess.
Comment #10
grendzy commentedSquare brackets are not valid URL characters. It would seem to me the bug is in OG for not encoding the square brackets.
http://www.ietf.org/rfc/rfc3986.txt
Comment #11
mstef commentedI'm pretty sure thats how arrays are passed as arguments. It has to be an array because multiple groups can be chosen. The problem is definitely in this module.
Comment #12
grendzy commentedmikestefff: You are correct PHP will interpret such requests as arrays, but they still need to be encoded to be valid URLs. The only reason these URLs work at all is because the browser's built-in error correction encodes them behind the scenes.
Comment #13
jwilson3OG may appear to be partially at fault for not using
urlencodeas Drupal recommends for the 'query' param (note no mention of RFC 3986 or rawurlencode). However, when I replace the faulty code with either urlencoded or rawurlencoded query strings, neither worked.Original code: (og.module, function og_og_create_links) produces a sample url like:
/node/add/discussion?gids[]=13235Once clicking the link SecurePages rebuilds the url like this:/node/add/discussion?gids=gids%255B0%255D%3D13235(as reported above).Wrapping the query string in either urlencode or urlrawencode, produces the same exact result -- a url like this:
/node/add/discussion?gids%5B%5D%3D13235.Unfortunately this still suffered from the original error reported above, generating the same resulting url:
/node/add/discussion?gids=gids%255B0%255D%3D13235.So I tried another solution using the Array format for the query option:
This time, it created perhaps the best looking url that is RFC 3986 compliant:
/node/add/discussion?gids%5B%5D=13235but it still sufferd from the original error reported in this issue. The URL was again rewritten to/node/add/discussion?gids=gids%255B0%255D%3D13235.Only after apply the patch in #9 did things start to work. As a matter of fact, all of the above started working, including the original unmodified organic groups code.
Some interesting sidenotes:
1) the Chrome browser displays ?gids%5B%5D=13235 as ?gids[]=13235 in both the url and the status bar (when hovering a link), but when I right click the link and copy the url, it does copy the fully url encoded string. Furthermore, equals signs dont follow this behavior as %3D doesn't get displayed as '='.
2) Drupal recommends that text strings passed to the 'query' option be encoded, but does not specify RFC 3986 ie rawurlencode(). So, to double check things, I passed "/node/add/discussion?gids[]=13235" as well as "/node/add/discussion?gids%5B%5D=13235" and even "/node/add/discussion?gids%5B%5D%3D13235" to Drupal's valid_url() to check for RFC 3986 compliance, and all of them returned TRUE.
The patch in #9 works great. Marking this as RTBC, and hoping that the maintainer would reconsider.
Comment #14
jwilson3I just updated to 6.x-1.9 and it looks like the logic in the securepages_get_query function has changes significantly, and the patch in #9 no longer applies, and furthermore, is no longer needed, according to my tests. Not sure which other thread in the issue queue resolved this error, so I guess the correct status for this is fixed?
Anyone else that was using this patch may wish to confirm with me that the update to 6.x-1.9 resolves this sufficiently.
Comment #15
wrightnow commentedConfirmed, we also just switched to 6.x.1.9 and the patch is no longer relevant nor required. The release notes for 1.9 mention http://drupal.org/node/420738 , which I suspect also solved this.