You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "Przemyslaw Budzik (JIRA)" <ji...@apache.org> on 2009/01/01 22:40:05 UTC
[jira] Created: (CAMEL-1211) camel-restlet security extension
camel-restlet security extension
--------------------------------
Key: CAMEL-1211
URL: https://issues.apache.org/activemq/browse/CAMEL-1211
Project: Apache Camel
Issue Type: Improvement
Components: camel-core
Affects Versions: 1.5.1, 2.0.0
Reporter: Przemyslaw Budzik
Priority: Minor
Now we have basic http auth. Quick shot is adding digest as it is supported by Restlet, but I have something more in mind. As I'm using token based auth and for me http auth is not suitable (pushing credentials back and forth all the time etc). How about a pattern where from one endpoint you can consume a ticket/token/sessionId and you can use it as a header to authenticate? As now the realm is to keep login and pass and it could be something like a bean that can validate the token. Of course that data would not be static so it is more about a callback (eg. getTokens()) than a static map/list. And finally as we have the uri we can resolve an "operation" and do authorization (so uri+method is the target). I mean in my project I have processor that does stuff like that and it would be cool to have all those things in one place in consumer (and provide only data and have skeletal logic under the hood).
Now the question is if my idea makes sense and if so what are your suggestions on how to implement that w/o reinventing the wheel (and not using ACEGI ;-))
Btw, Claus, William - logs about attaching/detaching restlets are at info level and it's kind of spamming if there are say 20 endpoints... Maybe it should be at debug?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1211) camel-restlet security extension
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=48425#action_48425 ]
Claus Ibsen commented on CAMEL-1211:
------------------------------------
Thanks for the INFO -> DEBUG patch. I have applied it to trunk and 1.x branch.
> camel-restlet security extension
> --------------------------------
>
> Key: CAMEL-1211
> URL: https://issues.apache.org/activemq/browse/CAMEL-1211
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core, camel-restlet
> Affects Versions: 1.5.1, 2.0.0
> Reporter: Przemyslaw Budzik
> Priority: Minor
> Attachments: info_to_debug.patch
>
>
> Now we have basic http auth. Quick shot is adding digest as it is supported by Restlet, but I have something more in mind. As I'm using token based auth and for me http auth is not suitable (pushing credentials back and forth all the time etc). How about a pattern where from one endpoint you can consume a ticket/token/sessionId and you can use it as a header to authenticate? As now the realm is to keep login and pass and it could be something like a bean that can validate the token. Of course that data would not be static so it is more about a callback (eg. getTokens()) than a static map/list. And finally as we have the uri we can resolve an "operation" and do authorization (so uri+method is the target). I mean in my project I have processor that does stuff like that and it would be cool to have all those things in one place in consumer (and provide only data and have skeletal logic under the hood).
> Now the question is if my idea makes sense and if so what are your suggestions on how to implement that w/o reinventing the wheel (and not using ACEGI ;-))
> Btw, Claus, William - logs about attaching/detaching restlets are at info level and it's kind of spamming if there are say 20 endpoints... Maybe it should be at debug?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1211) camel-restlet security extension
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen updated CAMEL-1211:
-------------------------------
Fix Version/s: 2.1.0
> camel-restlet security extension
> --------------------------------
>
> Key: CAMEL-1211
> URL: https://issues.apache.org/activemq/browse/CAMEL-1211
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core, camel-restlet
> Affects Versions: 1.6.0, 2.0.0
> Reporter: Przemyslaw Budzik
> Priority: Minor
> Fix For: 2.1.0
>
> Attachments: info_to_debug.patch
>
>
> Now we have basic http auth. Quick shot is adding digest as it is supported by Restlet, but I have something more in mind. As I'm using token based auth and for me http auth is not suitable (pushing credentials back and forth all the time etc). How about a pattern where from one endpoint you can consume a ticket/token/sessionId and you can use it as a header to authenticate? As now the realm is to keep login and pass and it could be something like a bean that can validate the token. Of course that data would not be static so it is more about a callback (eg. getTokens()) than a static map/list. And finally as we have the uri we can resolve an "operation" and do authorization (so uri+method is the target). I mean in my project I have processor that does stuff like that and it would be cool to have all those things in one place in consumer (and provide only data and have skeletal logic under the hood).
> Now the question is if my idea makes sense and if so what are your suggestions on how to implement that w/o reinventing the wheel (and not using ACEGI ;-))
> Btw, Claus, William - logs about attaching/detaching restlets are at info level and it's kind of spamming if there are say 20 endpoints... Maybe it should be at debug?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1211) camel-restlet security extension
Posted by "Przemyslaw Budzik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=48418#action_48418 ]
Przemyslaw Budzik commented on CAMEL-1211:
------------------------------------------
Claus,
It is connected with a consumer's life-cycle so it doesn't take place per request, but anyway if you have many routes with many endpoints and in tests you tend to start/stop Camel on setUp/tearDown it is quite verbose. You're right it is not obvious that's why I was asking not claiming :)
> camel-restlet security extension
> --------------------------------
>
> Key: CAMEL-1211
> URL: https://issues.apache.org/activemq/browse/CAMEL-1211
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core, camel-restlet
> Affects Versions: 1.5.1, 2.0.0
> Reporter: Przemyslaw Budzik
> Priority: Minor
>
> Now we have basic http auth. Quick shot is adding digest as it is supported by Restlet, but I have something more in mind. As I'm using token based auth and for me http auth is not suitable (pushing credentials back and forth all the time etc). How about a pattern where from one endpoint you can consume a ticket/token/sessionId and you can use it as a header to authenticate? As now the realm is to keep login and pass and it could be something like a bean that can validate the token. Of course that data would not be static so it is more about a callback (eg. getTokens()) than a static map/list. And finally as we have the uri we can resolve an "operation" and do authorization (so uri+method is the target). I mean in my project I have processor that does stuff like that and it would be cool to have all those things in one place in consumer (and provide only data and have skeletal logic under the hood).
> Now the question is if my idea makes sense and if so what are your suggestions on how to implement that w/o reinventing the wheel (and not using ACEGI ;-))
> Btw, Claus, William - logs about attaching/detaching restlets are at info level and it's kind of spamming if there are say 20 endpoints... Maybe it should be at debug?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1211) camel-restlet security extension
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen updated CAMEL-1211:
-------------------------------
Component/s: camel-restlet
> camel-restlet security extension
> --------------------------------
>
> Key: CAMEL-1211
> URL: https://issues.apache.org/activemq/browse/CAMEL-1211
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core, camel-restlet
> Affects Versions: 1.5.1, 2.0.0
> Reporter: Przemyslaw Budzik
> Priority: Minor
>
> Now we have basic http auth. Quick shot is adding digest as it is supported by Restlet, but I have something more in mind. As I'm using token based auth and for me http auth is not suitable (pushing credentials back and forth all the time etc). How about a pattern where from one endpoint you can consume a ticket/token/sessionId and you can use it as a header to authenticate? As now the realm is to keep login and pass and it could be something like a bean that can validate the token. Of course that data would not be static so it is more about a callback (eg. getTokens()) than a static map/list. And finally as we have the uri we can resolve an "operation" and do authorization (so uri+method is the target). I mean in my project I have processor that does stuff like that and it would be cool to have all those things in one place in consumer (and provide only data and have skeletal logic under the hood).
> Now the question is if my idea makes sense and if so what are your suggestions on how to implement that w/o reinventing the wheel (and not using ACEGI ;-))
> Btw, Claus, William - logs about attaching/detaching restlets are at info level and it's kind of spamming if there are say 20 endpoints... Maybe it should be at debug?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1211) camel-restlet security extension
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=48419#action_48419 ]
Claus Ibsen commented on CAMEL-1211:
------------------------------------
Przemyslaw,
If you have a patch handy with the DEBUG then I am sure we will commit it quickly :)
> camel-restlet security extension
> --------------------------------
>
> Key: CAMEL-1211
> URL: https://issues.apache.org/activemq/browse/CAMEL-1211
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core, camel-restlet
> Affects Versions: 1.5.1, 2.0.0
> Reporter: Przemyslaw Budzik
> Priority: Minor
>
> Now we have basic http auth. Quick shot is adding digest as it is supported by Restlet, but I have something more in mind. As I'm using token based auth and for me http auth is not suitable (pushing credentials back and forth all the time etc). How about a pattern where from one endpoint you can consume a ticket/token/sessionId and you can use it as a header to authenticate? As now the realm is to keep login and pass and it could be something like a bean that can validate the token. Of course that data would not be static so it is more about a callback (eg. getTokens()) than a static map/list. And finally as we have the uri we can resolve an "operation" and do authorization (so uri+method is the target). I mean in my project I have processor that does stuff like that and it would be cool to have all those things in one place in consumer (and provide only data and have skeletal logic under the hood).
> Now the question is if my idea makes sense and if so what are your suggestions on how to implement that w/o reinventing the wheel (and not using ACEGI ;-))
> Btw, Claus, William - logs about attaching/detaching restlets are at info level and it's kind of spamming if there are say 20 endpoints... Maybe it should be at debug?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1211) camel-restlet security extension
Posted by "Przemyslaw Budzik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Przemyslaw Budzik updated CAMEL-1211:
-------------------------------------
Attachment: info_to_debug.patch
> camel-restlet security extension
> --------------------------------
>
> Key: CAMEL-1211
> URL: https://issues.apache.org/activemq/browse/CAMEL-1211
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core, camel-restlet
> Affects Versions: 1.5.1, 2.0.0
> Reporter: Przemyslaw Budzik
> Priority: Minor
> Attachments: info_to_debug.patch
>
>
> Now we have basic http auth. Quick shot is adding digest as it is supported by Restlet, but I have something more in mind. As I'm using token based auth and for me http auth is not suitable (pushing credentials back and forth all the time etc). How about a pattern where from one endpoint you can consume a ticket/token/sessionId and you can use it as a header to authenticate? As now the realm is to keep login and pass and it could be something like a bean that can validate the token. Of course that data would not be static so it is more about a callback (eg. getTokens()) than a static map/list. And finally as we have the uri we can resolve an "operation" and do authorization (so uri+method is the target). I mean in my project I have processor that does stuff like that and it would be cool to have all those things in one place in consumer (and provide only data and have skeletal logic under the hood).
> Now the question is if my idea makes sense and if so what are your suggestions on how to implement that w/o reinventing the wheel (and not using ACEGI ;-))
> Btw, Claus, William - logs about attaching/detaching restlets are at info level and it's kind of spamming if there are say 20 endpoints... Maybe it should be at debug?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1211) camel-restlet security extension
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=48416#action_48416 ]
Claus Ibsen commented on CAMEL-1211:
------------------------------------
Is the INFO logging not only happening at startup? Or do they log quite often at runtime as well?
Choosing the right logging level is not as easy. Some wants all at DEBUG others sensible defaults at INFO etc.
> camel-restlet security extension
> --------------------------------
>
> Key: CAMEL-1211
> URL: https://issues.apache.org/activemq/browse/CAMEL-1211
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core
> Affects Versions: 1.5.1, 2.0.0
> Reporter: Przemyslaw Budzik
> Priority: Minor
>
> Now we have basic http auth. Quick shot is adding digest as it is supported by Restlet, but I have something more in mind. As I'm using token based auth and for me http auth is not suitable (pushing credentials back and forth all the time etc). How about a pattern where from one endpoint you can consume a ticket/token/sessionId and you can use it as a header to authenticate? As now the realm is to keep login and pass and it could be something like a bean that can validate the token. Of course that data would not be static so it is more about a callback (eg. getTokens()) than a static map/list. And finally as we have the uri we can resolve an "operation" and do authorization (so uri+method is the target). I mean in my project I have processor that does stuff like that and it would be cool to have all those things in one place in consumer (and provide only data and have skeletal logic under the hood).
> Now the question is if my idea makes sense and if so what are your suggestions on how to implement that w/o reinventing the wheel (and not using ACEGI ;-))
> Btw, Claus, William - logs about attaching/detaching restlets are at info level and it's kind of spamming if there are say 20 endpoints... Maybe it should be at debug?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-1211) camel-restlet security extension
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Willem Jiang resolved CAMEL-1211.
---------------------------------
Resolution: Fixed
Fix Version/s: (was: 2.3.0)
1.6.0
2.0-M1
> camel-restlet security extension
> --------------------------------
>
> Key: CAMEL-1211
> URL: https://issues.apache.org/activemq/browse/CAMEL-1211
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core, camel-restlet
> Affects Versions: 1.6.0, 2.0.0
> Reporter: Przemyslaw Budzik
> Priority: Minor
> Fix For: 2.0-M1, 1.6.0
>
> Attachments: info_to_debug.patch
>
>
> Now we have basic http auth. Quick shot is adding digest as it is supported by Restlet, but I have something more in mind. As I'm using token based auth and for me http auth is not suitable (pushing credentials back and forth all the time etc). How about a pattern where from one endpoint you can consume a ticket/token/sessionId and you can use it as a header to authenticate? As now the realm is to keep login and pass and it could be something like a bean that can validate the token. Of course that data would not be static so it is more about a callback (eg. getTokens()) than a static map/list. And finally as we have the uri we can resolve an "operation" and do authorization (so uri+method is the target). I mean in my project I have processor that does stuff like that and it would be cool to have all those things in one place in consumer (and provide only data and have skeletal logic under the hood).
> Now the question is if my idea makes sense and if so what are your suggestions on how to implement that w/o reinventing the wheel (and not using ACEGI ;-))
> Btw, Claus, William - logs about attaching/detaching restlets are at info level and it's kind of spamming if there are say 20 endpoints... Maybe it should be at debug?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.