From fh at mohegan-skunkworks.com Tue Jan 3 23:53:04 2012 From: fh at mohegan-skunkworks.com (mohegan-skunkworks) Date: Tue, 3 Jan 2012 18:53:04 -0500 Subject: [drakma-devel] cl-oauth and drakma interoperability issue In-Reply-To: <191E4CAC-228E-4A12-BC63-45225C10C64F@mohegan-skunkworks.com> References: <191E4CAC-228E-4A12-BC63-45225C10C64F@mohegan-skunkworks.com> Message-ID: <9BAFE5B7-8A10-4FA9-98CE-91F4F011F531@mohegan-skunkworks.com> Hi, is this the right mailing list for this issue ? Thanks ! On Dec 29, 2011, at 1:01 PM, mohegan-skunkworks wrote: > I just filled an issue on github... > > The text is below... > Hi, > I'm using cl-oauth to authenticate with twitter (it's in the cl-twitter package, also on github). > > I received a complaint from a quicklisp user that he couldn't authenticate with twitter. > > After looking into this a bit I realized that drakma is encoding the uri on get requests. Now, cl-oauth passes in an encoded uri so this uri gets encoded twice. This was never a problem for me because I was using v 1.2.3 of drakma where this didn't happen. > > Here's the code diff (plus my proposed change :) > ========================== v 1.2.3 ================================== > (when (and (not parameters-used-p) > parameters) > (setf (uri-query uri) > ;; append parameters to existing query of URI > (format nil "~@[~A~]~:*~:[~;&~]~A" > (uri-query uri) > (alist-to-url-encoded-string parameters external-format-out)))) > > ===========================current github/v1.2.4============= > (when-let (all-get-parameters > (append (dissect-query (uri-query uri)) > (and (not parameters-used-p) parameters))) > (setf (uri-query uri) > (alist-to-url-encoded-string all-get-parameters external-format-out))) > ===============================my proposed change=================================================== > (when (and (not parameters-used-p) > parameters) > (when-let (all-get-parameters > (append (dissect-query (uri-query uri)) > (and (not parameters-used-p) parameters))) > (setf (uri-query uri) > (alist-to-url-encoded-string all-get-parameters external-format-out)))) > > A few more comments : > > This is the hand-off in cl-oauth : > > (defun http-request (uri &key (request-method :get) parameters drakma-args) > ;; TODO handle redirects properly > (let* ((param-string-encoded (alist->query-string parameters :include-leading-ampersand nil :url-encode t))) > (case request-method > (:get > (apply #'drakma:http-request > (uri-with-additional-query-part uri param-string-encoded) > :method request-method > drakma-args)) > (:post > (apply #'drakma:http-request > uri > :method request-method > :content param-string-encoded > drakma-args)) > > As you can see url-encode is set to t. That was because (I think !) previous versions required encoding and drakma wasn't providing any. Now, ideally tis flag s/b nil. However the issue the becomes the string splitting in dissect-query. This splits on "=" which is also the terminating symbol for the authentication string... > =======================session=================== > (drakma::split-string "oauth_signature=oq37d1/qm[....]fIKb778=&include_entities=T&oauth_consumer_key=9[....]cYBg&oauth_token=206[...]Tt5SwRvCJqQWgR3ajEQpk&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1325002586&oauth_nonce=3680613621135035286&oauth_version=1.0" "&") > ("oauth_signature=oq37d1/qmFX0YuQUwxsgfIKb778=" "include_entities=T" > [....]) > > CL-USER> (drakma::split-string "oauth_signature=oq37d1/qmFX0YuQUwxsgfIKb778=" "=") > ; compiling (DEFUN HTTP-REQUEST ...) > STYLE-WARNING: redefining DRAKMA:HTTP-REQUEST in DEFUN > > ("oauth_signature" "oq37d1/qm[...]778") > (I've elided some of the strings...). > > I think my proposal resolves the issue. However, it would require a bit more work to get to what I think is the 'right' solution... > > At this stage I'd like to get some feedback on whta you consider the right course of action before proceeding to submit a patch > > _______________________________________________ > drakma-devel mailing list > drakma-devel at common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at weitz.de Wed Jan 4 14:54:49 2012 From: edi at weitz.de (Edi Weitz) Date: Wed, 4 Jan 2012 15:54:49 +0100 Subject: [drakma-devel] cl-oauth and drakma interoperability issue In-Reply-To: <9BAFE5B7-8A10-4FA9-98CE-91F4F011F531@mohegan-skunkworks.com> References: <191E4CAC-228E-4A12-BC63-45225C10C64F@mohegan-skunkworks.com> <9BAFE5B7-8A10-4FA9-98CE-91F4F011F531@mohegan-skunkworks.com> Message-ID: It is, but see here: http://lists.common-lisp.net/pipermail/drakma-devel/2011-August/000884.html On Wed, Jan 4, 2012 at 12:53 AM, mohegan-skunkworks wrote: > Hi, is this the right mailing list for this issue ? > > Thanks ! > On Dec 29, 2011, at 1:01 PM, mohegan-skunkworks wrote: > > I just filled an issue on github... > > The text is below... > > Hi, > I'm using cl-oauth to authenticate with twitter (it's in the cl-twitter > package, also on github). > > I received a complaint from a quicklisp user that he couldn't authenticate > with twitter. > > After looking into this a bit I realized that drakma is encoding the uri on > get requests. Now, cl-oauth passes in an encoded uri so this uri gets > encoded twice. This was never a problem for me because I was using v 1.2.3 > of drakma where this didn't happen. > > Here's the code diff (plus my proposed change :) > ========================== v 1.2.3 ================================== > (when (and (not parameters-used-p) > parameters) > (setf (uri-query uri) > ;; append parameters to existing query of URI > (format nil "~@[~A~]~:*~:[~;&~]~A" > (uri-query uri) > (alist-to-url-encoded-string parameters external-format-out)))) > > ===========================current github/v1.2.4============= > (when-let (all-get-parameters > (append (dissect-query (uri-query uri)) > (and (not parameters-used-p) parameters))) > (setf (uri-query uri) > (alist-to-url-encoded-string all-get-parameters external-format-out))) > ===============================my proposed > change=================================================== > (when (and (not parameters-used-p) > parameters) > (when-let (all-get-parameters > (append (dissect-query (uri-query uri)) > (and (not parameters-used-p) parameters))) > (setf (uri-query uri) > (alist-to-url-encoded-string all-get-parameters external-format-out)))) > > ________________________________ > > A few more comments : > > This is the hand-off in cl-oauth : > > (defun http-request (uri &key (request-method :get) parameters drakma-args) > ? ;; TODO handle redirects properly > ? (let* ((param-string-encoded (alist->query-string parameters > :include-leading-ampersand nil?:url-encode t))) > ? ? (case request-method > ? ? ? (:get > ? ? ? ?(apply #'drakma:http-request > ?? ? ?(uri-with-additional-query-part uri param-string-encoded) > ?? ? ?:method request-method > ?? ? ?drakma-args)) > ? ? ? (:post > ? ? ? ? (apply #'drakma:http-request > ? ? ? ? ? ? ? ?uri > ? ? ? ? ? ? ? ?:method request-method > ? ? ? ? ? ? ? ?:content param-string-encoded > ? ? ? ? ? ? ? ?drakma-args)) > > As you can see url-encode is set to t. That was because (I think !) previous > versions required encoding and drakma wasn't providing any. Now, ideally tis > flag s/b nil. However the issue the becomes the string splitting in > dissect-query. This splits on "=" which is also the terminating symbol for > the authentication string... > =======================session=================== > (drakma::split-string > "oauth_signature=oq37d1/qm[....]fIKb778=&include_entities=T&oauth_consumer_key=9[....]cYBg&oauth_token=206[...]Tt5SwRvCJqQWgR3ajEQpk&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1325002586&oauth_nonce=3680613621135035286&oauth_version=1.0" > "&") > ("oauth_signature=oq37d1/qmFX0YuQUwxsgfIKb778=" "include_entities=T" > [....]) > > CL-USER> (drakma::split-string > "oauth_signature=oq37d1/qmFX0YuQUwxsgfIKb778=" "=") > ; compiling (DEFUN HTTP-REQUEST ...) > STYLE-WARNING: redefining DRAKMA:HTTP-REQUEST in DEFUN > > ("oauth_signature" "oq37d1/qm[...]778") > > (I've elided some of the strings...). > > I think my proposal resolves the issue. However, it would require a bit more > work to get to what I think is the 'right' solution... > > At this stage I'd like to get some feedback on whta you consider the right > course of action before proceeding to submit a patch > > _______________________________________________ > drakma-devel mailing list > drakma-devel at common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel > > > > _______________________________________________ > drakma-devel mailing list > drakma-devel at common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel > From fh at mohegan-skunkworks.com Sat Jan 7 21:50:11 2012 From: fh at mohegan-skunkworks.com (mohegan-skunkworks) Date: Sat, 7 Jan 2012 16:50:11 -0500 Subject: [drakma-devel] cl-oauth and drakma interoperability issue In-Reply-To: References: <191E4CAC-228E-4A12-BC63-45225C10C64F@mohegan-skunkworks.com> <9BAFE5B7-8A10-4FA9-98CE-91F4F011F531@mohegan-skunkworks.com> Message-ID: ok, does this mean that this library is no longer maintained ? On Jan 4, 2012, at 9:54 AM, Edi Weitz wrote: > It is, but see here: > > http://lists.common-lisp.net/pipermail/drakma-devel/2011-August/000884.html > > On Wed, Jan 4, 2012 at 12:53 AM, mohegan-skunkworks > wrote: >> Hi, is this the right mailing list for this issue ? >> >> Thanks ! >> On Dec 29, 2011, at 1:01 PM, mohegan-skunkworks wrote: >> >> I just filled an issue on github... >> >> The text is below... >> >> Hi, >> I'm using cl-oauth to authenticate with twitter (it's in the cl-twitter >> package, also on github). >> >> I received a complaint from a quicklisp user that he couldn't authenticate >> with twitter. >> >> After looking into this a bit I realized that drakma is encoding the uri on >> get requests. Now, cl-oauth passes in an encoded uri so this uri gets >> encoded twice. This was never a problem for me because I was using v 1.2.3 >> of drakma where this didn't happen. >> >> Here's the code diff (plus my proposed change :) >> ========================== v 1.2.3 ================================== >> (when (and (not parameters-used-p) >> parameters) >> (setf (uri-query uri) >> ;; append parameters to existing query of URI >> (format nil "~@[~A~]~:*~:[~;&~]~A" >> (uri-query uri) >> (alist-to-url-encoded-string parameters external-format-out)))) >> >> ===========================current github/v1.2.4============= >> (when-let (all-get-parameters >> (append (dissect-query (uri-query uri)) >> (and (not parameters-used-p) parameters))) >> (setf (uri-query uri) >> (alist-to-url-encoded-string all-get-parameters external-format-out))) >> ===============================my proposed >> change=================================================== >> (when (and (not parameters-used-p) >> parameters) >> (when-let (all-get-parameters >> (append (dissect-query (uri-query uri)) >> (and (not parameters-used-p) parameters))) >> (setf (uri-query uri) >> (alist-to-url-encoded-string all-get-parameters external-format-out)))) >> >> ________________________________ >> >> A few more comments : >> >> This is the hand-off in cl-oauth : >> >> (defun http-request (uri &key (request-method :get) parameters drakma-args) >> ;; TODO handle redirects properly >> (let* ((param-string-encoded (alist->query-string parameters >> :include-leading-ampersand nil :url-encode t))) >> (case request-method >> (:get >> (apply #'drakma:http-request >> (uri-with-additional-query-part uri param-string-encoded) >> :method request-method >> drakma-args)) >> (:post >> (apply #'drakma:http-request >> uri >> :method request-method >> :content param-string-encoded >> drakma-args)) >> >> As you can see url-encode is set to t. That was because (I think !) previous >> versions required encoding and drakma wasn't providing any. Now, ideally tis >> flag s/b nil. However the issue the becomes the string splitting in >> dissect-query. This splits on "=" which is also the terminating symbol for >> the authentication string... >> =======================session=================== >> (drakma::split-string >> "oauth_signature=oq37d1/qm[....]fIKb778=&include_entities=T&oauth_consumer_key=9[....]cYBg&oauth_token=206[...]Tt5SwRvCJqQWgR3ajEQpk&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1325002586&oauth_nonce=3680613621135035286&oauth_version=1.0" >> "&") >> ("oauth_signature=oq37d1/qmFX0YuQUwxsgfIKb778=" "include_entities=T" >> [....]) >> >> CL-USER> (drakma::split-string >> "oauth_signature=oq37d1/qmFX0YuQUwxsgfIKb778=" "=") >> ; compiling (DEFUN HTTP-REQUEST ...) >> STYLE-WARNING: redefining DRAKMA:HTTP-REQUEST in DEFUN >> >> ("oauth_signature" "oq37d1/qm[...]778") >> >> (I've elided some of the strings...). >> >> I think my proposal resolves the issue. However, it would require a bit more >> work to get to what I think is the 'right' solution... >> >> At this stage I'd like to get some feedback on whta you consider the right >> course of action before proceeding to submit a patch >> >> _______________________________________________ >> drakma-devel mailing list >> drakma-devel at common-lisp.net >> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel >> >> >> >> _______________________________________________ >> drakma-devel mailing list >> drakma-devel at common-lisp.net >> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel >> > > _______________________________________________ > drakma-devel mailing list > drakma-devel at common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel > From xach at xach.com Sat Jan 7 22:06:54 2012 From: xach at xach.com (Zach Beane) Date: Sat, 07 Jan 2012 17:06:54 -0500 Subject: [drakma-devel] cl-oauth and drakma interoperability issue In-Reply-To: (mohegan-skunkworks's message of "Sat, 7 Jan 2012 16:50:11 -0500") References: <191E4CAC-228E-4A12-BC63-45225C10C64F@mohegan-skunkworks.com> <9BAFE5B7-8A10-4FA9-98CE-91F4F011F531@mohegan-skunkworks.com> Message-ID: <87aa5zmakh.fsf@hangup.portland.xach.com> mohegan-skunkworks writes: > ok, does this mean that this library is no longer maintained ? For what it's worth, I had a similar issue with ZS3, but rewriting ZS3 to pass parameters as :parameters instead of in the URL worked to fix it. Zach From fh at mohegan-skunkworks.com Sat Jan 7 22:24:32 2012 From: fh at mohegan-skunkworks.com (mohegan-skunkworks) Date: Sat, 7 Jan 2012 17:24:32 -0500 Subject: [drakma-devel] cl-oauth and drakma interoperability issue In-Reply-To: <87aa5zmakh.fsf@hangup.portland.xach.com> References: <191E4CAC-228E-4A12-BC63-45225C10C64F@mohegan-skunkworks.com> <9BAFE5B7-8A10-4FA9-98CE-91F4F011F531@mohegan-skunkworks.com> <87aa5zmakh.fsf@hangup.portland.xach.com> Message-ID: <5B4CCBBF-FA4A-419C-B6E8-BE84163609D2@mohegan-skunkworks.com> thanks for the feedback... I'll take a closer look at cl-oauth then... On Jan 7, 2012, at 5:06 PM, Zach Beane wrote: > mohegan-skunkworks writes: > >> ok, does this mean that this library is no longer maintained ? > > For what it's worth, I had a similar issue with ZS3, but rewriting ZS3 > to pass parameters as :parameters instead of in the URL worked to fix > it. > > Zach > > _______________________________________________ > drakma-devel mailing list > drakma-devel at common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel > From edi at weitz.de Sun Jan 8 01:31:31 2012 From: edi at weitz.de (Edi Weitz) Date: Sun, 8 Jan 2012 02:31:31 +0100 Subject: [drakma-devel] cl-oauth and drakma interoperability issue In-Reply-To: References: <191E4CAC-228E-4A12-BC63-45225C10C64F@mohegan-skunkworks.com> <9BAFE5B7-8A10-4FA9-98CE-91F4F011F531@mohegan-skunkworks.com> Message-ID: On Sat, Jan 7, 2012 at 10:50 PM, mohegan-skunkworks wrote: > ok, does this mean that this library is no longer maintained ? It means that I currently don't have the time to maintain it. But you can check out the github repository and see what's happening there: http://netzhansa.blogspot.com/2011/08/ediware-moving-to-github.html Cheers, Edi. From fh at mohegan-skunkworks.com Sun Jan 8 02:28:13 2012 From: fh at mohegan-skunkworks.com (mohegan-skunkworks) Date: Sat, 7 Jan 2012 21:28:13 -0500 Subject: [drakma-devel] cl-oauth and drakma interoperability issue In-Reply-To: References: <191E4CAC-228E-4A12-BC63-45225C10C64F@mohegan-skunkworks.com> <9BAFE5B7-8A10-4FA9-98CE-91F4F011F531@mohegan-skunkworks.com> Message-ID: <98B95D62-2B58-442A-B1B0-E4AA02F73FFC@mohegan-skunkworks.com> got it, thanks for the follow up. I appreciate it ! On Jan 7, 2012, at 8:31 PM, Edi Weitz wrote: > On Sat, Jan 7, 2012 at 10:50 PM, mohegan-skunkworks > wrote: >> ok, does this mean that this library is no longer maintained ? > > It means that I currently don't have the time to maintain it. But you > can check out the github repository and see what's happening there: > > http://netzhansa.blogspot.com/2011/08/ediware-moving-to-github.html > > Cheers, > Edi. > > _______________________________________________ > drakma-devel mailing list > drakma-devel at common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel > From rob.blackwell at robblackwell.org.uk Sat Jan 14 12:15:11 2012 From: rob.blackwell at robblackwell.org.uk (Rob Blackwell) Date: Sat, 14 Jan 2012 12:15:11 +0000 Subject: [drakma-devel] Drakma and client certificates? Message-ID: <3069AB75-270B-4670-B7AC-29B75C149837@robblackwell.org.uk> Hi, I'm trying to use client certificates with Drakma to call an existing web based API. I have the latest code from https://github.com/edicl/drakma installed in my quicklisp local-projects directory. I'm using SBCL on OS X and Linux. The client certificate is a .pfx file, and I've converted it to .pem format using openssl pkcs12 -in robblackwellmanage.pfx -out robblackwellmanage.pfx.pem I have verfied that this works as a server certifcate, using hunchentoot, thus: (hunchentoot:start (make-instance 'hunchentoot:ssl-acceptor :ssl-privatekey-file "/Users/reb/certs/robblackwellmanage.pfx.pem" :ssl-certificate-file "/Users/reb/certs/robblackwellmanage.pfx.pem" :ssl-privatekey-password "password" :port 4343)) When I try to use this as a client certificate: (drakma:http-request resource :certificate "/Users/reb/certs/robblackwellmanage.pfx.pem" :key "/Users/reb/certs/robblackwellmanage.pfx.pem" :certificate-password "password" :method :get :content "" :content-type "application/xml" :additional-headers headers) I get the following error SSL initialization error: Can't load certificate passwordSSL error queue is empty. [Condition of type CL+SSL::SSL-ERROR-INITIALIZE] Interestingly, if I deliberately supply the wrong password then I get a different error SSL initialization error: Can't load RSA private key file /Users/reb/certs/robblackwellmanage.pfx.pemSSL error queue is empty. [Condition of type CL+SSL::SSL-ERROR-INITIALIZE] I guess I'm doing something really silly - please excuse my ignorance, but any advice, suggestions or guidance on how to proceed would be very much appreciated. Thanks! Rob From rob.blackwell at robblackwell.org.uk Sat Jan 14 18:41:24 2012 From: rob.blackwell at robblackwell.org.uk (Rob Blackwell) Date: Sat, 14 Jan 2012 18:41:24 +0000 Subject: [drakma-devel] Drakma and client certificates? Message-ID: <74436BB1-0B76-4CBF-B01A-5A728C628621@robblackwell.org.uk> Okay, I think it was a typo in the Drakma util.lisp file - I have issued a pull request on github to fix it. https://github.com/RobBlackwell/drakma/commit/149e445e39faa940fb211b7dd627161b7fd0c5df Thanks, Rob.