You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@manifoldcf.apache.org by "Karl Wright (JIRA)" <ji...@apache.org> on 2012/09/10 12:16:08 UTC

[jira] [Commented] (CONNECTORS-518) Wiki Connector support for API authorization and security tokens

    [ https://issues.apache.org/jira/browse/CONNECTORS-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451863#comment-13451863 ] 

Karl Wright commented on CONNECTORS-518:
----------------------------------------

I've had a look at the login functionality.  Since you are keeping hold of an HttpClient instance for the entire lifetime of a session, cookies should stick to that instance.  This should be OK.  However, each individual HttpClient instance will need to log in itself, so you will have a lot of logins - but perhaps that is OK too.

I am puzzled, however, why you have the following:

{code}
      connectionManager.getParams().setMaxTotalConnections(20);
{code}

Since this is local to the connection instance, there should need to be one connection per instance, so it seems to me that you can leave this at 1 and be fine.  If you set up a global pool in Commons HttpClient 3.x, it segregates cookies only by server name, and there may be different credentials depending on which connection was in play, so we cannot use a global pool even if we wanted to.

So I think the only other thing we need to fix is explicit support for session timeout.  Am I correct in assuming that you get back a 401 error when session has timed out on a document fetch?  Is there anything in the payload which would indicate session timeout instead of general inaccessibility?

                
> Wiki Connector support for API authorization and security tokens
> ----------------------------------------------------------------
>
>                 Key: CONNECTORS-518
>                 URL: https://issues.apache.org/jira/browse/CONNECTORS-518
>             Project: ManifoldCF
>          Issue Type: Improvement
>          Components: Wiki connector
>    Affects Versions: ManifoldCF 0.6
>            Reporter: Maciej Lizewski
>            Assignee: Karl Wright
>             Fix For: ManifoldCF next
>
>         Attachments: WikiConnector.java, wiki.zip
>
>
> Wiki connector does not support API with restricted access (there is "login" method in API: https://www.mediawiki.org/wiki/API:Login)
> There is no "security" tab for forced authorization tokens or any other security implemented. There should be at least forced tokens tab or tokens assigned to wiki namespaces (second would be better)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jira] [Commented] (CONNECTORS-518) Wiki Connector support for API authorization and security tokens

Posted by Maciej Liżewski <ma...@gmail.com>.
yes :)

2012/9/10 Karl Wright <da...@gmail.com>

> Ok, I understand - so the maximum number of connections you actually
> need are 2, not 20. ;-)
>
> Karl
>
> On Mon, Sep 10, 2012 at 8:36 AM, Maciej Liżewski
> <ma...@gmail.com> wrote:
> > OK. will try to explain:
> >
> > there is only one HttpClient for Connector instance. But it has tohandle
> > multiple request. During login process it has to handle 2 connections
> > (first try to login and if the server returns TokenRequired answer -
> second
> > connection but the first may not be disconnected that time). So I had to
> > increase setMaxTotalConnections, because oryginally there was a limit
> > setMaxTotalConnections(1),
> > which caused deadlocks in situations described earlier. I think there
> could
> > be "unlimited" option as well.
> >
> > As there is only one instance of HttpClient per Connector instance per
> > session - there are not so many "login" requests - in fact only one per
> > session when the HttpClient is instantiated and is maintained until
> > Connector::disconnect() is called (which kills HttpClient instance).
> >
> > When session expires there is no 40x response unfortunately, but there is
> > error message in payload:
> >
> > <?xml version="1.0"?>
> > <api><error info="You need read permission to use this module"
> > code="readapidenied"/></api>
> >
> > it could be used to handle "session expired" situation, but should be
> > checked on every API request...
> >
> >
> > 2012/9/10 Karl Wright (JIRA) <ji...@apache.org>
> >
> >>
> >>     [
> >>
> https://issues.apache.org/jira/browse/CONNECTORS-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451863#comment-13451863
> ]
> >>
> >> Karl Wright commented on CONNECTORS-518:
> >> ----------------------------------------
> >>
> >> I've had a look at the login functionality.  Since you are keeping hold
> of
> >> an HttpClient instance for the entire lifetime of a session, cookies
> should
> >> stick to that instance.  This should be OK.  However, each individual
> >> HttpClient instance will need to log in itself, so you will have a lot
> of
> >> logins - but perhaps that is OK too.
> >>
> >> I am puzzled, however, why you have the following:
> >>
> >> {code}
> >>       connectionManager.getParams().setMaxTotalConnections(20);
> >> {code}
> >>
> >> Since this is local to the connection instance, there should need to be
> >> one connection per instance, so it seems to me that you can leave this
> at 1
> >> and be fine.  If you set up a global pool in Commons HttpClient 3.x, it
> >> segregates cookies only by server name, and there may be different
> >> credentials depending on which connection was in play, so we cannot use
> a
> >> global pool even if we wanted to.
> >>
> >> So I think the only other thing we need to fix is explicit support for
> >> session timeout.  Am I correct in assuming that you get back a 401 error
> >> when session has timed out on a document fetch?  Is there anything in
> the
> >> payload which would indicate session timeout instead of general
> >> inaccessibility?
> >>
> >>
> >> > Wiki Connector support for API authorization and security tokens
> >> > ----------------------------------------------------------------
> >> >
> >> >                 Key: CONNECTORS-518
> >> >                 URL:
> >> https://issues.apache.org/jira/browse/CONNECTORS-518
> >> >             Project: ManifoldCF
> >> >          Issue Type: Improvement
> >> >          Components: Wiki connector
> >> >    Affects Versions: ManifoldCF 0.6
> >> >            Reporter: Maciej Lizewski
> >> >            Assignee: Karl Wright
> >> >             Fix For: ManifoldCF next
> >> >
> >> >         Attachments: WikiConnector.java, wiki.zip
> >> >
> >> >
> >> > Wiki connector does not support API with restricted access (there is
> >> "login" method in API: https://www.mediawiki.org/wiki/API:Login)
> >> > There is no "security" tab for forced authorization tokens or any
> other
> >> security implemented. There should be at least forced tokens tab or
> tokens
> >> assigned to wiki namespaces (second would be better)
> >>
> >> --
> >> This message is automatically generated by JIRA.
> >> If you think it was sent incorrectly, please contact your JIRA
> >> administrators
> >> For more information on JIRA, see:
> http://www.atlassian.com/software/jira
> >>
>

Re: [jira] [Commented] (CONNECTORS-518) Wiki Connector support for API authorization and security tokens

Posted by Karl Wright <da...@gmail.com>.
Ok, I understand - so the maximum number of connections you actually
need are 2, not 20. ;-)

Karl

On Mon, Sep 10, 2012 at 8:36 AM, Maciej Liżewski
<ma...@gmail.com> wrote:
> OK. will try to explain:
>
> there is only one HttpClient for Connector instance. But it has tohandle
> multiple request. During login process it has to handle 2 connections
> (first try to login and if the server returns TokenRequired answer - second
> connection but the first may not be disconnected that time). So I had to
> increase setMaxTotalConnections, because oryginally there was a limit
> setMaxTotalConnections(1),
> which caused deadlocks in situations described earlier. I think there could
> be "unlimited" option as well.
>
> As there is only one instance of HttpClient per Connector instance per
> session - there are not so many "login" requests - in fact only one per
> session when the HttpClient is instantiated and is maintained until
> Connector::disconnect() is called (which kills HttpClient instance).
>
> When session expires there is no 40x response unfortunately, but there is
> error message in payload:
>
> <?xml version="1.0"?>
> <api><error info="You need read permission to use this module"
> code="readapidenied"/></api>
>
> it could be used to handle "session expired" situation, but should be
> checked on every API request...
>
>
> 2012/9/10 Karl Wright (JIRA) <ji...@apache.org>
>
>>
>>     [
>> https://issues.apache.org/jira/browse/CONNECTORS-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451863#comment-13451863]
>>
>> Karl Wright commented on CONNECTORS-518:
>> ----------------------------------------
>>
>> I've had a look at the login functionality.  Since you are keeping hold of
>> an HttpClient instance for the entire lifetime of a session, cookies should
>> stick to that instance.  This should be OK.  However, each individual
>> HttpClient instance will need to log in itself, so you will have a lot of
>> logins - but perhaps that is OK too.
>>
>> I am puzzled, however, why you have the following:
>>
>> {code}
>>       connectionManager.getParams().setMaxTotalConnections(20);
>> {code}
>>
>> Since this is local to the connection instance, there should need to be
>> one connection per instance, so it seems to me that you can leave this at 1
>> and be fine.  If you set up a global pool in Commons HttpClient 3.x, it
>> segregates cookies only by server name, and there may be different
>> credentials depending on which connection was in play, so we cannot use a
>> global pool even if we wanted to.
>>
>> So I think the only other thing we need to fix is explicit support for
>> session timeout.  Am I correct in assuming that you get back a 401 error
>> when session has timed out on a document fetch?  Is there anything in the
>> payload which would indicate session timeout instead of general
>> inaccessibility?
>>
>>
>> > Wiki Connector support for API authorization and security tokens
>> > ----------------------------------------------------------------
>> >
>> >                 Key: CONNECTORS-518
>> >                 URL:
>> https://issues.apache.org/jira/browse/CONNECTORS-518
>> >             Project: ManifoldCF
>> >          Issue Type: Improvement
>> >          Components: Wiki connector
>> >    Affects Versions: ManifoldCF 0.6
>> >            Reporter: Maciej Lizewski
>> >            Assignee: Karl Wright
>> >             Fix For: ManifoldCF next
>> >
>> >         Attachments: WikiConnector.java, wiki.zip
>> >
>> >
>> > Wiki connector does not support API with restricted access (there is
>> "login" method in API: https://www.mediawiki.org/wiki/API:Login)
>> > There is no "security" tab for forced authorization tokens or any other
>> security implemented. There should be at least forced tokens tab or tokens
>> assigned to wiki namespaces (second would be better)
>>
>> --
>> This message is automatically generated by JIRA.
>> If you think it was sent incorrectly, please contact your JIRA
>> administrators
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>

Re: [jira] [Commented] (CONNECTORS-518) Wiki Connector support for API authorization and security tokens

Posted by Maciej Liżewski <ma...@gmail.com>.
OK. will try to explain:

there is only one HttpClient for Connector instance. But it has tohandle
multiple request. During login process it has to handle 2 connections
(first try to login and if the server returns TokenRequired answer - second
connection but the first may not be disconnected that time). So I had to
increase setMaxTotalConnections, because oryginally there was a limit
setMaxTotalConnections(1),
which caused deadlocks in situations described earlier. I think there could
be "unlimited" option as well.

As there is only one instance of HttpClient per Connector instance per
session - there are not so many "login" requests - in fact only one per
session when the HttpClient is instantiated and is maintained until
Connector::disconnect() is called (which kills HttpClient instance).

When session expires there is no 40x response unfortunately, but there is
error message in payload:

<?xml version="1.0"?>
<api><error info="You need read permission to use this module"
code="readapidenied"/></api>

it could be used to handle "session expired" situation, but should be
checked on every API request...


2012/9/10 Karl Wright (JIRA) <ji...@apache.org>

>
>     [
> https://issues.apache.org/jira/browse/CONNECTORS-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451863#comment-13451863]
>
> Karl Wright commented on CONNECTORS-518:
> ----------------------------------------
>
> I've had a look at the login functionality.  Since you are keeping hold of
> an HttpClient instance for the entire lifetime of a session, cookies should
> stick to that instance.  This should be OK.  However, each individual
> HttpClient instance will need to log in itself, so you will have a lot of
> logins - but perhaps that is OK too.
>
> I am puzzled, however, why you have the following:
>
> {code}
>       connectionManager.getParams().setMaxTotalConnections(20);
> {code}
>
> Since this is local to the connection instance, there should need to be
> one connection per instance, so it seems to me that you can leave this at 1
> and be fine.  If you set up a global pool in Commons HttpClient 3.x, it
> segregates cookies only by server name, and there may be different
> credentials depending on which connection was in play, so we cannot use a
> global pool even if we wanted to.
>
> So I think the only other thing we need to fix is explicit support for
> session timeout.  Am I correct in assuming that you get back a 401 error
> when session has timed out on a document fetch?  Is there anything in the
> payload which would indicate session timeout instead of general
> inaccessibility?
>
>
> > Wiki Connector support for API authorization and security tokens
> > ----------------------------------------------------------------
> >
> >                 Key: CONNECTORS-518
> >                 URL:
> https://issues.apache.org/jira/browse/CONNECTORS-518
> >             Project: ManifoldCF
> >          Issue Type: Improvement
> >          Components: Wiki connector
> >    Affects Versions: ManifoldCF 0.6
> >            Reporter: Maciej Lizewski
> >            Assignee: Karl Wright
> >             Fix For: ManifoldCF next
> >
> >         Attachments: WikiConnector.java, wiki.zip
> >
> >
> > Wiki connector does not support API with restricted access (there is
> "login" method in API: https://www.mediawiki.org/wiki/API:Login)
> > There is no "security" tab for forced authorization tokens or any other
> security implemented. There should be at least forced tokens tab or tokens
> assigned to wiki namespaces (second would be better)
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA
> administrators
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>