From cl-openid-devel at common-lisp.net Sun Jun 5 22:22:40 2011 From: cl-openid-devel at common-lisp.net (cl-openid) Date: Sun, 05 Jun 2011 22:22:40 -0000 Subject: [cl-openid-ticket] [cl-openid] #14: secure random number generation In-Reply-To: <064.4bec06e8d542b57d5ca46dc48faac343@common-lisp.net> References: <064.4bec06e8d542b57d5ca46dc48faac343@common-lisp.net> Message-ID: <073.d05f9b6410be43f07059968125f0a00f@common-lisp.net> #14: secure random number generation ---------------------------+------------------------------------------------ Reporter: mpasternacki | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: code | Version: 1.1 extended Resolution: fixed | Keywords: ---------------------------+------------------------------------------------ Changes (by avodonosov): * status: new => closed * resolution: => fixed Comment: The ticket is fixed. A library for secure random numbers is implemented: https://github.com/avodonosov/secure-random/. The current implementation is not pure-lisp, it reuses OpenSSL random number generator (via cl+ssl). Pure-lisp library would be better probably, but the OpenSSL way was the simpler. Implementing a pure lisp secure random number generator not only requires the RNG algorithm coding; the most expensive part will be gathering a truly unguessable initial state for the generator. OpenSSL does this from a platform specific service, like /dev/random, Windows Crypto API, Entropy Gathering Daemon, etc. The secure-random interface hides the implementation details, so when (and if) it will be reimplemented in lisp, the cl-openid code will not be affected. cl-openid already unconditionally depends on cl+ssl via drakma, therefore this solution does not add a redundant dependency. As of today, secure-random is not on quicklisp. Also it uses the very fresh cl+ssl with is also not in quicklisp. To trt it just download the secure random snapshot: http://github.com/avodonosov/secure-random/tarball/master. Then download the cl+ssl snapshot: https://gitorious.org/cl-plus-ssl/cl- plus-ssl/archive-tarball/master {{{ (pushnew "" asdf:*central-registry* :test #'equal) (pushnew "" asdf:*central-registry* :test #'equal) (pushnew "" asdf:*central-registry* :test #'equal) (ql:quickload :cl-openid) }}} -- Ticket URL: cl-openid cl-openid From cl-openid-devel at common-lisp.net Sun Jun 5 22:28:29 2011 From: cl-openid-devel at common-lisp.net (cl-openid) Date: Sun, 05 Jun 2011 22:28:29 -0000 Subject: [cl-openid-ticket] [cl-openid] #16: unit test error: make-auth-proc Message-ID: <062.c26b0e9c96f9ea0813b38216fb4b193d@common-lisp.net> #16: unit test error: make-auth-proc ------------------------+--------------------------------------------------- Reporter: avodonosov | Owner: Type: defect | Status: new Priority: major | Milestone: Component: code | Version: 1.0 portable Keywords: unit-test | ------------------------+--------------------------------------------------- The test output: {{{ Did 239 checks. Pass: 234 (97%) Skip: 0 ( 0%) Fail: 5 ( 2%) Failure Details: -------------------------------- MAKE-AUTH-PROCESS []: Failed to signal a ERROR. -------------------------------- -------------------------------- MAKE-AUTH-PROCESS []: (CDR TEST-CASE) evaluated to "http://example.com/", which is not STRING= to "http://www.iana.org/domains/example/".. -------------------------------- -------------------------------- MAKE-AUTH-PROCESS []: (CDR TEST-CASE) evaluated to "http://example.com/", which is not STRING= to "http://www.iana.org/domains/example/".. -------------------------------- -------------------------------- MAKE-AUTH-PROCESS []: (CDR TEST-CASE) evaluated to "http://example.com/", which is not STRING= to "http://www.iana.org/domains/example/".. -------------------------------- -------------------------------- MAKE-AUTH-PROCESS []: Unexpected Error: # Could not reach http://common-lisp.net/project/cl-openid/index.shtml/: 404 Not Found.. -------------------------------- }}} The reason of most of these errors (except the last probably) is that today http://example.com/ just redirects to http://www.iana.org/domains/example/, and in particular, http://example.com/nonexistent also redirects, and after the redirect returns HTTP 200 OK. -- Ticket URL: cl-openid cl-openid From cl-openid-devel at common-lisp.net Sun Jun 5 22:39:25 2011 From: cl-openid-devel at common-lisp.net (cl-openid) Date: Sun, 05 Jun 2011 22:39:25 -0000 Subject: [cl-openid-ticket] [cl-openid] #17: signal an error if discovery didn't discovered anything Message-ID: <062.3e8b0522ab0ed2c41698108db9da1c4c@common-lisp.net> #17: signal an error if discovery didn't discovered anything ------------------------+--------------------------------------------------- Reporter: avodonosov | Owner: Type: defect | Status: new Priority: major | Milestone: Component: code | Version: 0.5 nonportable Keywords: | ------------------------+--------------------------------------------------- If discovery process doesn't discover the necessary information (provider endpoint at least, but we should check by the spec the minimum required attribute list), the function should signal an error, instead of leaving NILs in the AUTHPROC structure, and allow the library fail later (which is inconvenient to debug). It's necessary to add a check to the end of the discovery process, that verifies that the required minimum of information is discovered. I encountered this problem when was recently testing with technorati.com - they previously were providing OpenID, and I registered an account. The OpenID identity URL is http://technorati.com/people/technorati/clopenid. Today this page does not have the tags necessary for discovery. In result, the discovery process just silently created an AUTHPROC struct with NILs. The error occurred somewhere later in the control flow. -- Ticket URL: cl-openid cl-openid From cl-openid-devel at common-lisp.net Mon Jun 6 08:06:09 2011 From: cl-openid-devel at common-lisp.net (cl-openid) Date: Mon, 06 Jun 2011 08:06:09 -0000 Subject: [cl-openid-ticket] [cl-openid] #17: signal an error if discovery didn't discovered anything In-Reply-To: <062.3e8b0522ab0ed2c41698108db9da1c4c@common-lisp.net> References: <062.3e8b0522ab0ed2c41698108db9da1c4c@common-lisp.net> Message-ID: <071.629e1e5b9c5a93e1b5a1503c14349d59@common-lisp.net> #17: signal an error if discovery didn't discovered anything ------------------------+--------------------------------------------------- Reporter: avodonosov | Owner: Type: defect | Status: new Priority: major | Milestone: Component: code | Version: 1.0 portable Keywords: | ------------------------+--------------------------------------------------- Changes (by avodonosov): * version: 0.5 nonportable => 1.0 portable -- Ticket URL: cl-openid cl-openid From cl-openid-devel at common-lisp.net Mon Jun 6 08:25:02 2011 From: cl-openid-devel at common-lisp.net (cl-openid) Date: Mon, 06 Jun 2011 08:25:02 -0000 Subject: [cl-openid-ticket] [cl-openid] #18: LiveJournal error reponse with HTTP status 200 Message-ID: <062.9f5ba883ee4c48f0440032f869cc051b@common-lisp.net> #18: LiveJournal error reponse with HTTP status 200 ------------------------+--------------------------------------------------- Reporter: avodonosov | Owner: Type: defect | Status: new Priority: major | Milestone: Component: code | Version: 1.0 portable Keywords: | ------------------------+--------------------------------------------------- Livejournal OpenID provider started to violate the spec (as I read it) by returning error response with HTTP status code 200 OK. When I tested Livejournal with cl-openid last time, it worked OK, but now it doesn't work. The relevant code: association.lisp, the function ASSOCIATE. It performs DIRECT-REQUEST and expects it to signal an OPENID-REQUEST-ERROR if the provider does not support the requested session type or association type ("error_code" = "unsupported-type"). In this case the condition handler retries the association request. The DIRECT-REQUEST only signals the error if the HTTP request status is not 200. But livejournal returns HTTP 200 OK and the message body contains "error_code" = "unsupported-type". I think it's a violation of the spec (see 5.1.2.2. Error Responses in the end of this section: http://openid.net/specs/openid-authentication- 2_0.html#direct_comm and 8.2.4. Unsuccessful Response Parameters in the end of this section: http://openid.net/specs/openid-authentication- 2_0.html#anchor20). Error responses must always be sent with status 400. But we have no other choice than support the livejournal behaviour. I am not sure where to handle it: 1. Inside of the DIRECT-REQUTEST, in addition to the HTTP status != 200, we may signal an error if the response message contains "error" attribute. 2. In the ASSOCIATE function, we might in addition to condition handler for OPENID-REQUEST-ERROR check that the message has attributes "error"; and if "error_code" = "unsupported-type" then retry the request with adjusted parameters. As the section 5.1.2.2. "Error Responses" (http://openid.net/specs/openid- authentication-2_0.html#direct_comm) specifies that the "error" attribute is mandatory for error responses, the variant 1 seems to be acceptable. -- Ticket URL: cl-openid cl-openid From cl-openid-devel at common-lisp.net Tue Jun 7 22:34:43 2011 From: cl-openid-devel at common-lisp.net (cl-openid) Date: Tue, 07 Jun 2011 22:34:43 -0000 Subject: [cl-openid-ticket] [cl-openid] #16: unit test error: make-auth-proc In-Reply-To: <062.c26b0e9c96f9ea0813b38216fb4b193d@common-lisp.net> References: <062.c26b0e9c96f9ea0813b38216fb4b193d@common-lisp.net> Message-ID: <071.a20004d5d9b8de62724c28751aea897e@common-lisp.net> #16: unit test error: make-auth-proc -------------------------+-------------------------------------------------- Reporter: avodonosov | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: code | Version: 1.0 portable Resolution: fixed | Keywords: unit-test -------------------------+-------------------------------------------------- Changes (by avodonosov): * status: new => closed * resolution: => fixed -- Ticket URL: cl-openid cl-openid From cl-openid-devel at common-lisp.net Wed Jun 8 22:07:40 2011 From: cl-openid-devel at common-lisp.net (cl-openid) Date: Wed, 08 Jun 2011 22:07:40 -0000 Subject: [cl-openid-ticket] [cl-openid] #17: signal an error if discovery discovers nothing (was: signal an error if discovery didn't discovered anything) In-Reply-To: <062.3e8b0522ab0ed2c41698108db9da1c4c@common-lisp.net> References: <062.3e8b0522ab0ed2c41698108db9da1c4c@common-lisp.net> Message-ID: <071.5af0fc90c769628b32f720aa0f16d374@common-lisp.net> #17: signal an error if discovery discovers nothing ------------------------+--------------------------------------------------- Reporter: avodonosov | Owner: Type: defect | Status: new Priority: major | Milestone: Component: code | Version: 1.0 portable Keywords: | ------------------------+--------------------------------------------------- -- Ticket URL: cl-openid cl-openid From cl-openid-devel at common-lisp.net Thu Jun 9 00:12:55 2011 From: cl-openid-devel at common-lisp.net (cl-openid) Date: Thu, 09 Jun 2011 00:12:55 -0000 Subject: [cl-openid-ticket] [cl-openid] #17: signal an error if discovery discovers nothing In-Reply-To: <062.3e8b0522ab0ed2c41698108db9da1c4c@common-lisp.net> References: <062.3e8b0522ab0ed2c41698108db9da1c4c@common-lisp.net> Message-ID: <071.02c494991561dfd4c2fabbabfc27a155@common-lisp.net> #17: signal an error if discovery discovers nothing -------------------------+-------------------------------------------------- Reporter: avodonosov | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: code | Version: 1.0 portable Resolution: fixed | Keywords: -------------------------+-------------------------------------------------- Changes (by avodonosov): * status: new => closed * resolution: => fixed Comment: Fixed. Not using this URL as an OpenID identifier correctly signals an error. -- Ticket URL: cl-openid cl-openid From cl-openid-devel at common-lisp.net Thu Jun 9 00:16:28 2011 From: cl-openid-devel at common-lisp.net (cl-openid) Date: Thu, 09 Jun 2011 00:16:28 -0000 Subject: [cl-openid-ticket] [cl-openid] #19: some polishment provider API Message-ID: <062.870f032b8b10409e2f7fcc013fb6bcf8@common-lisp.net> #19: some polishment provider API ------------------------+--------------------------------------------------- Reporter: avodonosov | Owner: Type: defect | Status: new Priority: major | Milestone: Component: code | Version: 1.0 portable Keywords: | ------------------------+--------------------------------------------------- See the suggestions here: http://lists.common-lisp.net/pipermail/cl-openid- devel/2008-September/000097.html -- Ticket URL: cl-openid cl-openid From cl-openid-devel at common-lisp.net Thu Jun 9 00:16:56 2011 From: cl-openid-devel at common-lisp.net (cl-openid) Date: Thu, 09 Jun 2011 00:16:56 -0000 Subject: [cl-openid-ticket] [cl-openid] #19: some polishment of the provider API (was: some polishment provider API) In-Reply-To: <062.870f032b8b10409e2f7fcc013fb6bcf8@common-lisp.net> References: <062.870f032b8b10409e2f7fcc013fb6bcf8@common-lisp.net> Message-ID: <071.0c927ec9d83752cfc089c33e8d57ecd8@common-lisp.net> #19: some polishment of the provider API ------------------------+--------------------------------------------------- Reporter: avodonosov | Owner: Type: defect | Status: new Priority: major | Milestone: Component: code | Version: 1.0 portable Keywords: | ------------------------+--------------------------------------------------- -- Ticket URL: cl-openid cl-openid From cl-openid-devel at common-lisp.net Thu Jun 9 00:26:48 2011 From: cl-openid-devel at common-lisp.net (cl-openid) Date: Thu, 09 Jun 2011 00:26:48 -0000 Subject: [cl-openid-ticket] [cl-openid] #17: signal an error if discovery discovers nothing In-Reply-To: <062.3e8b0522ab0ed2c41698108db9da1c4c@common-lisp.net> References: <062.3e8b0522ab0ed2c41698108db9da1c4c@common-lisp.net> Message-ID: <071.8b1661acf305427cf46a1b9626ff2642@common-lisp.net> #17: signal an error if discovery discovers nothing -------------------------+-------------------------------------------------- Reporter: avodonosov | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: code | Version: 1.0 portable Resolution: fixed | Keywords: -------------------------+-------------------------------------------------- Comment(by avodonosov): Replying to [comment:3 avodonosov]: > Fixed. Not using this URL as an OpenID identifier correctly signals an error. > *Now* using this URL.... -- Ticket URL: cl-openid cl-openid From cl-openid-devel at common-lisp.net Thu Jun 9 00:32:53 2011 From: cl-openid-devel at common-lisp.net (cl-openid) Date: Thu, 09 Jun 2011 00:32:53 -0000 Subject: [cl-openid-ticket] [cl-openid] #14: secure random number generation In-Reply-To: <064.4bec06e8d542b57d5ca46dc48faac343@common-lisp.net> References: <064.4bec06e8d542b57d5ca46dc48faac343@common-lisp.net> Message-ID: <073.88544ffd4f4573929a8fd1b6821c8de5@common-lisp.net> #14: secure random number generation ---------------------------+------------------------------------------------ Reporter: mpasternacki | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: code | Version: 1.0 portable Resolution: fixed | Keywords: ---------------------------+------------------------------------------------ Changes (by avodonosov): * version: 1.1 extended => 1.0 portable -- Ticket URL: cl-openid cl-openid From cl-openid-devel at common-lisp.net Fri Jun 10 22:58:49 2011 From: cl-openid-devel at common-lisp.net (cl-openid) Date: Fri, 10 Jun 2011 22:58:49 -0000 Subject: [cl-openid-ticket] [cl-openid] #18: LiveJournal error reponse with HTTP status 200 In-Reply-To: <062.9f5ba883ee4c48f0440032f869cc051b@common-lisp.net> References: <062.9f5ba883ee4c48f0440032f869cc051b@common-lisp.net> Message-ID: <071.40b123084857a5f006b2f431f2d42c90@common-lisp.net> #18: LiveJournal error reponse with HTTP status 200 -------------------------+-------------------------------------------------- Reporter: avodonosov | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: code | Version: 1.0 portable Resolution: fixed | Keywords: -------------------------+-------------------------------------------------- Changes (by avodonosov): * status: new => closed * resolution: => fixed Comment: Fixed by adding a check for the "error" attribute in the response in the DIRECT-REQUEST function (vent if the HTTP status code is 200 OK). Now LiveJournal OpenID authentication works OK. -- Ticket URL: cl-openid cl-openid From cl-openid-devel at common-lisp.net Sat Jun 11 02:18:40 2011 From: cl-openid-devel at common-lisp.net (cl-openid) Date: Sat, 11 Jun 2011 02:18:40 -0000 Subject: [cl-openid-ticket] [cl-openid] #19: some polishment of the provider API In-Reply-To: <062.870f032b8b10409e2f7fcc013fb6bcf8@common-lisp.net> References: <062.870f032b8b10409e2f7fcc013fb6bcf8@common-lisp.net> Message-ID: <071.faf91914b900d9346ec17cdde3ad29d4@common-lisp.net> #19: some polishment of the provider API ------------------------+--------------------------------------------------- Reporter: avodonosov | Owner: avodonosov Type: defect | Status: assigned Priority: major | Milestone: Component: code | Version: 1.0 portable Keywords: | ------------------------+--------------------------------------------------- Changes (by avodonosov): * owner: => avodonosov * status: new => assigned -- Ticket URL: cl-openid cl-openid From cl-openid-devel at common-lisp.net Sat Jun 11 22:49:27 2011 From: cl-openid-devel at common-lisp.net (cl-openid) Date: Sat, 11 Jun 2011 22:49:27 -0000 Subject: [cl-openid-ticket] [cl-openid] #20: user_setup_url automatic generation Message-ID: <062.0f4002b4e35de2078a4de4dc9ced9164@common-lisp.net> #20: user_setup_url automatic generation ------------------------+--------------------------------------------------- Reporter: avodonosov | Owner: Type: defect | Status: new Priority: major | Milestone: Component: code | Version: 1.0 portable Keywords: 1-1-compat | ------------------------+--------------------------------------------------- To be compatible with OpenID Authentication 1.1 the OP should, include field user_setup_url into responses to checkid_immediate requests preformed using the 1.1 vesion of the protocol. RP may redirect user to this URI where user can complete the authentication (by interacting with the OP web UI, like login form, etc.). After the user interaction with OP is done, the user should be returned to the RP, with positive or negative assertion, the same way it is done for checkid_setup requests. In the 2.0 version of OpenID Authenctiaction these requirement for OP was replaced by just possibility for RP to perform new authorization request, now in checkid_setup mode, if the checkid_immediate has failed. (it was a good solution, because simplified the OP implementation). In the current cl-openid implementation we just provided a generic function USER-SETUP-URL which we suggest to programmer using our library to re-implement. The programmer is expected to provide some URL and create a handler for that URL and take care of whatever is needed to redirect the users browser back to RP when necessary. This is very complex task for the programmer. Instead, cl-openid might just change the request mode from checkid_immediate to checkid_stetup, then generate the OP endpoint URL passing the adjusted request in parameters. If the RP will use this URL, the OP handling will reuse all the checkid_setup logic. This should work, because the authorization requests sent by RP are not signed, therefore OP may easily adjust the requests. The relevant spec links: OpenID Authentication 2.0 - Final 14.2. Implementing OpenID Authentication 1.1 Compatibility http://openid.net/specs/openid-authentication-2_0.html#anchor38 OpenID Authentication 1.1 4.2.3. Extra Notes http://openid.net/specs/openid-authentication-1_1.html#anchor21 -- Ticket URL: cl-openid cl-openid From cl-openid-devel at common-lisp.net Sat Jun 11 22:51:59 2011 From: cl-openid-devel at common-lisp.net (cl-openid) Date: Sat, 11 Jun 2011 22:51:59 -0000 Subject: [cl-openid-ticket] [cl-openid] #20: user_setup_url automatic generation In-Reply-To: <062.0f4002b4e35de2078a4de4dc9ced9164@common-lisp.net> References: <062.0f4002b4e35de2078a4de4dc9ced9164@common-lisp.net> Message-ID: <071.5a4f7a63e670c6b559fe85a28fb91774@common-lisp.net> #20: user_setup_url automatic generation ------------------------+--------------------------------------------------- Reporter: avodonosov | Owner: Type: defect | Status: new Priority: major | Milestone: Component: code | Version: 1.0 portable Keywords: 1-1-compat | ------------------------+--------------------------------------------------- Comment(by avodonosov): After fixing this ticket the generic function should be removed in it's current form USER-SETUP-URL. Another small fix is that the user_setup_url handling should *only* be user if the authentication request is of version 1.1. -- Ticket URL: cl-openid cl-openid From cl-openid-devel at common-lisp.net Sat Jun 11 22:53:59 2011 From: cl-openid-devel at common-lisp.net (cl-openid) Date: Sat, 11 Jun 2011 22:53:59 -0000 Subject: [cl-openid-ticket] [cl-openid] #21: INITIATE-AUTHENTICATION: return the URI as a string Message-ID: <062.e5bd2e115a5c6d5d318bbaf6293b5eb9@common-lisp.net> #21: INITIATE-AUTHENTICATION: return the URI as a string ------------------------+--------------------------------------------------- Reporter: avodonosov | Owner: Type: defect | Status: new Priority: major | Milestone: Component: code | Version: 1.0 portable Keywords: | ------------------------+--------------------------------------------------- To be consistent with the recent provider API changes (the ticket #19), the URI returned from INITIATE-AUTHENTICATION should be of type string. This saves the user one PRINC-TO-STRING in his code. -- Ticket URL: cl-openid cl-openid From cl-openid-devel at common-lisp.net Sat Jun 11 22:57:28 2011 From: cl-openid-devel at common-lisp.net (cl-openid) Date: Sat, 11 Jun 2011 22:57:28 -0000 Subject: [cl-openid-ticket] [cl-openid] #22: adjust the exampels to hunchentoot 1.1. Message-ID: <062.187bf1d117d811313f568d3b8d236334@common-lisp.net> #22: adjust the exampels to hunchentoot 1.1. ------------------------+--------------------------------------------------- Reporter: avodonosov | Owner: Type: defect | Status: new Priority: major | Milestone: Component: code | Version: 1.0 portable Keywords: | ------------------------+--------------------------------------------------- -- Ticket URL: cl-openid cl-openid From cl-openid-devel at common-lisp.net Sun Jun 12 00:53:31 2011 From: cl-openid-devel at common-lisp.net (cl-openid) Date: Sun, 12 Jun 2011 00:53:31 -0000 Subject: [cl-openid-ticket] [cl-openid] #19: some polishment of the provider API In-Reply-To: <062.870f032b8b10409e2f7fcc013fb6bcf8@common-lisp.net> References: <062.870f032b8b10409e2f7fcc013fb6bcf8@common-lisp.net> Message-ID: <071.7fc62abaf669640d6b1dcfe80a8d378d@common-lisp.net> #19: some polishment of the provider API -------------------------+-------------------------------------------------- Reporter: avodonosov | Owner: avodonosov Type: defect | Status: closed Priority: major | Milestone: Component: code | Version: 1.0 portable Resolution: fixed | Keywords: -------------------------+-------------------------------------------------- Changes (by avodonosov): * status: assigned => closed * resolution: => fixed Comment: The changes implemented: - HANDLE-OPENID-PROVIDER-REQUEST always returns the second value, an HTTP code. When the HTTP code is redirect (3xx), the first value URI is returned as a string, instead of a PURI:URI object. This saves user from doing PRINC-TO-STRING for the URI. - CANCEL-RESPONSE and SUCCESSFUL-RESPONSE are renamed to CANCEL-RESPONSE- URI and SUCCESSFUL-RESPONSE-URI. Both functions return only single value - the URI (no sense to return the HTTP status code as the second value, as this is always recirect). The URI is returned as a string instead of PURI:URI instance. - Removed WITH-INDIRECT-ERROR-HANDLER and SIGNAL-INDIRECT-ERROR from the public API. - Introduced new public function AUTH-REQUEST-REALM with returns the realm of the OpenID authentication request message. - The HANDLE-OPENID-PROVIDER-REQUEST keyword parameter SECURE-P is renamed to ALLOW-UNENCRYPTED-ASSOCIATION-P. - Some adjustments in the docs. -- Ticket URL: cl-openid cl-openid