It seems like the orkut's certificate is wrong (or something else), because i've created my own certificate with my own private key, and the example works like a charm, so the Signed Request is OK =)
G.- On Fri, Jul 18, 2008 at 4:11 PM, Karsten Beyer <[EMAIL PROTECTED]> wrote: > Hi, > the patch was against trunk at the time of posting it. No further > modifications were necessary. > > Can you log the base_string which is generated in OAuth.php Line 199 > (OAuthSignatureMethod_RSA_SHA1->build_signature) and the one which is > generated by the example code in the OAuth.php Library file > (OAuthSignatureMethod_RSA_SHA1->check_signature) and send them both? That > would help in locating the problem that you are experiencing. > > (Assuming that the problem is that the signature cannot be verified...) > > Regards, > > Karsten > > On Fri, Jul 18, 2008 at 8:42 PM, Gonzalo Aune <[EMAIL PROTECTED]> > wrote: > > > Karsten, > > > > applying the patch to my current shindig, didnt solved any problem, the > > example isnt working for me, did you have to do extra modifications to > any > > file?. > > > > G.- > > > > On Fri, Jul 18, 2008 at 1:38 PM, Karsten Beyer (JIRA) <[EMAIL PROTECTED]> > > wrote: > > > > > > > > [ > > > > > > https://issues.apache.org/jira/browse/SHINDIG-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > > ] > > > > > > Karsten Beyer updated SHINDIG-447: > > > ---------------------------------- > > > > > > Attachment: fix-issue-447.patch > > > > > > As promised, attached a patch to fix the situation. However the issue > > > seemed to be a lot worse than first expected. So i will first describe > my > > > analysis of the problems with the current code. > > > > > > There is a method to sanitize the fields (GET+POST) which go into the > > > base_string used for the signature. It is located in SigningFetcher and > > > relies on this method: > > > > > > protected static $ALLOWED_PARAM_NAME = "[-:\\w]+"; > > > > > > ... > > > > > > private function allowParam($paramName) > > > { > > > $canonParamName = strtolower($paramName); > > > return (! (substr($canonParamName, 0, 5) == "oauth" || > > > substr($canonParamName, 0, 6) == "xoauth" || substr($canonParamName, 0, > > 9) > > > == "opensocial")) && ereg(SigningFetcher::$ALLOWED_PARAM_NAME, > > > $canonParamName); > > > } > > > > > > > > > Now this filters all parameters which either start with one of the > > strings > > > in the first half of the expression or which do not contain a 'w'(!). > For > > > this reason, stuff like "numentries" or "myvalueformyscript" is being > > thrown > > > away, while "signOwner" and "signViewer" are kept. This is in my > opinion > > a > > > completely wrong behavior. I will present a solution to it later on. > > > > > > Next problem is that the values are only appended to the query string, > if > > > they were not posted to the proxy (which is ok, if we are supposed to > do > > a > > > POST). This affects both the signViewer and signOwner fields as > > everything > > > is posted to the proxy. Bad thing is that the POST data and headers are > > not > > > set, so we effectively do a GET instead of the requested POST. > > > > > > The OAuthRequest object now builds its base_string using all > "sanitized" > > > values in the GET+POST array. This contains at this point in time: > > > > > > 1) signViewer & signOwner > > > 2) all Fields of the user not containing a 'w' > > > > > > They are not used in the final request string however, as they are POST > > > data. Therefore the signature validation cannot work. > > > > > > Now to my solution (This patch is rather complex, so it would be a good > > > idea to review it carefully before applying it): > > > > > > > > > 1) I "fixed" the regular expression to accept alphanum, 0-9, -, _. > > However > > > this is a very bad idea. As i understand, special chars are allowed for > > form > > > field names, they just need to be encoded in a POST. Maybe someone has > a > > > good idea here. '\w' is as far as i know not available with the POSIX > > > regular expressions. > > > > > > 2) As i understood the OAuth specification, the posted form data needs > to > > > be included in the base_string used for the signature. This is > transfered > > to > > > the proxy in the postData field of the $_POST. I implemented a parsing > > > function which put the (sanitized) single entries into the postParams > > > arrays, so they are used for the generation of the signature and also > for > > > the building of the query string / or postdata string (see below). > > > > > > 3) The sanitize function obviously did not work at all. If you fix it > > > however, all the parameters which are supposed to be for the proxy, are > > now > > > in the base_string as well as the query string. So i extended the > > allowParam > > > method to exclude all these parameters (e.g. url, gadget, > bypassspeccache > > > etc.). This includes the postData param, as we put these values > > individually > > > into the postParam array. > > > > > > 4) If we have a POST request, i build a post_data string according to > > > RFC3986 using the oauth library which is later used to actually post > the > > > data. If we have a GET request however, i leave the post data string == > > > false in order to make a GET request to the partners page and keep the > > > forPost array empty so that these are appended to the query string > > instead. > > > Take a look at this example to understand why: > > > > > > testdataplain = new Object(); > > > testdataplain['hello'] = 'world'; > > > params[gadgets.io.RequestParameters.CONTENT_TYPE] = > > > gadgets.io.ContentType.TEXT; > > > params[gadgets.io.RequestParameters.AUTHORIZATION] = > > > gadgets.io.AuthorizationType.SIGNED > > > params[gadgets.io.RequestParameters.METHOD] = > gadgets.io.MethodType.GET; > > > params[gadgets.io.RequestParameters.POST_DATA] = > > > gadgets.io.encodeValues(testdataplain); > > > > > > gadgets.io.makeRequest(' > > > http://opensocialapps.kbsilver/log.php?hope=itworks', gotLog, params); > > > > > > Obviously i would expect to get the values hello=world&hope=itworks in > a > > > signed request. > > > > > > 5) Last of all, if we do a POST, i add the constructed post_data array > > (see > > > 4) and the $_POST['headers'] field to the contructor of > > RemoteContentRequest > > > in order to actually make a POST. > > > > > > 6) I removed the quick hack from the OAuth.php file. > > > > > > > > > > > > > > > > > > > > > > makeRequest - Signed request cannot be verified because of > base_string > > > inconsitency > > > > > > > > > > ----------------------------------------------------------------------------------- > > > > > > > > Key: SHINDIG-447 > > > > URL: > https://issues.apache.org/jira/browse/SHINDIG-447 > > > > Project: Shindig > > > > Issue Type: Bug > > > > Components: Common Components (PHP) > > > > Reporter: Karsten Beyer > > > > Attachments: fix-issue-447.patch > > > > > > > > > > > > When doing a signed request with makeRequest, the generated signature > > > cannot be verified, because different base_strings are used. > > > > I used the method described for Orkut ( > > > > > > http://code.google.com/p/opensocial-resources/wiki/OrkutValidatingSignedRequests > > ) > > > to verify the signature on the requested page. When logging the > > base_string > > > on both sides, i detected, that the signOwner and signViewer parameters > > are > > > used for the base_string, but are not part of the request that the > proxy > > > does to the target page: > > > > base_string build by shindig: > > > > > > > > > > GET&http%3A%2F%2Fopensocialapps.kbsilver%2Flog.php&container%3Dazubister%26oauth_consumer_key%3Dnot%2520implemented%26oauth_nonce%3D68d2fedb1b405f426e0b5d6aa90893bb%26oauth_signature_method%3DRSA-SHA1%26oauth_timestamp%3D1215874245%26oauth_token%3D%26opensocial_app_id%3D25%26opensocial_owner_id%3DQ3czQ1B2SytHbVU0ZXJEOXRwOTJHdz09%26opensocial_viewer_id%3DQ3czQ1B2SytHbVU0ZXJEOXRwOTJHdz09%26signOwner%3Dtrue%26signViewer%3Dtrue%26synd%3Dazubister%26xoauth_signature_publickey%3Dhttp%253A%252F%252Fshindig.kbsilver%252Fpublic.crt > > > > base_string build at the requested page: > > > > > > > > > > GET&http%3A%2F%2Fopensocialapps.kbsilver%2Flog.php&container%3Dazubister%26oauth_consumer_key%3Dnot%2520implemented%26oauth_nonce%3D68d2fedb1b405f426e0b5d6aa90893bb%26oauth_signature_method%3DRSA-SHA1%26oauth_timestamp%3D1215874245%26oauth_token%3D%26opensocial_app_id%3D25%26opensocial_owner_id%3DQ3czQ1B2SytHbVU0ZXJEOXRwOTJHdz09%26opensocial_viewer_id%3DQ3czQ1B2SytHbVU0ZXJEOXRwOTJHdz09%26synd%3Dazubister%26xoauth_signature_publickey%3Dhttp%253A%252F%252Fshindig.kbsilver%252Fpublic.crt > > > > Analyzing the $_GET parameters i get at the target leads to the same > > > result. I do not know enough about the OAUTH logic in shindig, but i > > think > > > either the signOwner and signViewer parameters need to be ignored when > > > building the base_string for the signature or they need to be part of > the > > > request to the target page. > > > > > > -- > > > This message is automatically generated by JIRA. > > > - > > > You can reply to this email to add a comment to the issue online. > > > > > > > > >
