[GitHub] cxf pull request: Downgrade loglevel for regular requests
GitHub user irsm opened a pull request: https://github.com/apache/cxf/pull/2 Downgrade loglevel for regular requests Every request, even if successful, results in many warning entries, alerting developer unnecessarily. This modification downgrades log level to "fine", like in "checkHttpVerb" method. So, regular and authorized requests do not increase log file with WARNS. You can merge this pull request into a Git repository by running: $ git pull https://github.com/irsm/cxf patch-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cxf/pull/2.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2 commit 2de9ca1c1e0ea6ce91214c8554936effd89d553b Author: Ibraim Rodrigues da Silva Medina Date: 2014-04-10T22:24:26Z Downgrade loglevel for regular requests Every request, even if successful, results in many warning entries, alerting developer unnecessarily. This modification downgrades log level to "fine", like in "checkHttpVerb" method. So, regular and authorized requests do not increase log file with WARNS. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
RE: Secure CXF rsServer with Jaas authentication
Hi, I am redirecting the question into user list, if you don't mind. I think OAuth 2.0 client credentials could be elegant solution for this case (https://cxf.apache.org/docs/jax-rs-oauth2.html). You will be able to authenticate client first time with HTTP basic credentials against OAuth Authentication Service (authentication can be JAAS based) and issue AccessToken (and RefreshToken). For further call Resource Service will validate AccessToken and you don't need to send HTTP basic credentials anymore. Second option is using SAML authentication token and STS with JAAS extension, but this is more involved (https://cxf.apache.org/docs/jax-rs-saml.html ). Does it make sense for you? Regards, Andrei. > -Original Message- > From: Honey Goyal [mailto:er.honey2...@gmail.com] > Sent: Donnerstag, 10. April 2014 10:06 > To: dev@cxf.apache.org > Subject: Secure CXF rsServer with Jaas authentication > > Hi, > > I am newbie to CXF. I have configured CXF JAASAuthenticationFilter to > authenticate by jaas realm to each rest call. But each time i had to pass > Basic > Authenticate header to authenticate it. Can i configure any token based login > along with JAAS? So that only first time it authenticate with jaas and return > any > auth token. Next time only i need that auth token to make call from client > side. > > This is my working blueprint > > >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"; > xmlns:camel="http://camel.apache.org/schema/blueprint"; > xmlns:cxf="http://camel.apache.org/schema/blueprint/cxf"; > xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.0.0"; > xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs"; > xsi:schemaLocation=" > http://www.osgi.org/xmlns/blueprint/v1.0.0 > http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd > http://camel.apache.org/schema/blueprint/cxf > http://camel.apache.org/schema/blueprint/cxf/camel-cxf.xsd > http://cxf.apache.org/blueprint/jaxrs > http://cxf.apache.org/schemas/blueprint/jaxrs.xsd > http://camel.apache.org/schema/blueprint > http://camel.apache.org/schema/blueprint/camel-blueprint.xsd"; > > > > >value="http://localhost:80/v1"; /> > > > >serviceClass="com..cp.securitytoken.SecurityTokenServiceImpl"> > > > > > > < bean id="authorizationFilter" > class="org.apache.cxf.jaxrs.security.JAASAuthenticationFilter"> >Name of the JAAS Context > > > > http://camel.apache.org/schema/blueprint"; > id="security"> > > > > > > > > > > > -- > View this message in context: http://cxf.547215.n5.nabble.com/Secure-CXF- > rsServer-with-Jaas-authentication-tp5742659.html > Sent from the cxf-dev mailing list archive at Nabble.com.
Re: [VOTE] CXF 2.6.14/2.7.11 - take 2
+1 On 09/04/14 05:44, Daniel Kulp wrote: It’s been 2 months since the last releases… This is a vote to release 2.7.11 and 2.6.14. There are over 60 issues fixed for 2.7.11 and more than 20 ported back to 2.6.14. This second attempt fixes the blueprint parsing issues that Aki found as well as a potential NPE in the Logging interceptors. Staging area: https://repository.apache.org/content/repositories/orgapachecxf-1017/ https://repository.apache.org/content/repositories/orgapachecxf-1018/ Tag: https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=22e7ed37f8967f6fc2e0035f3b56eb5b882e0582 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=0245050c1c326a6bfa26186806615dc311686946 This vote will be open for 72 hours. -- Alessio Soldano Web Service Lead, JBoss
Re: [VOTE] CXF 2.6.14/2.7.11 - take 2
Ran some tests with camel-cxf, every thing looks good. Here is my +1. -- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On April 9, 2014 at 11:45:09 AM, Daniel Kulp (dk...@apache.org) wrote: > > > It’s been 2 months since the last releases… This is a vote to release 2.7.11 > and 2.6.14. > > There are over 60 issues fixed for 2.7.11 and more than 20 ported back to > 2.6.14. > > > This second attempt fixes the blueprint parsing issues that Aki found as well > as a potential > NPE in the Logging interceptors. > > > Staging area: > https://repository.apache.org/content/repositories/orgapachecxf-1017/ > https://repository.apache.org/content/repositories/orgapachecxf-1018/ > > Tag: > https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=22e7ed37f8967f6fc2e0035f3b56eb5b882e0582 > > https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=0245050c1c326a6bfa26186806615dc311686946 > > > This vote will be open for 72 hours. > > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > >
Re: JTA support for JMS Transport in CXF 3.0
Hi Christian, a few thoughts inline (not having looked at any of the code yet). I am currently working on the transaction support (resource local and JTA) for the JMS transport in CXF 3. In a chat with Dan we found that it is not fully clear what we expect from the transaction support. So I will do a coarse design here on the list and hope to get some feedback on what you expect and would like to see. The general principle on kind of "container" managed transaction support is to open a transaction when a message is received. Then the message is processed inside the transaction. If an exception happens in the processing the transaction is rolled back and the JMS server tries some redeliveries. If these all fail the message goes to the dead letter queue. If the processing runs without an exception the transaction and so the message will be committed. Service side: - Support transactions only for One Way messaging. I think for request reply there is always a client on the other side who can retry when a message is lost and the client also wants some feedback about errors on the server side. This sounded interesting at first sight (to allow transparent retry/failover) but propably will only lead to recv or transaction timeout for most deployments. Still, might be a nice to have to actually have a chance to get a transaction allowing for rollback, if one were to make such experiments, and have one started automatically. But then an error reply should be committed in any case if not explicitly rolled back. - For one way exchanges I propose to roll back on any exceptions as it is the simplest case. We might also support to permanently fail a message on things like invalid xml as this will probably also fail the next time. It is difficult to correctly specify when to roll back and when to fail in this case. Checked exceptions from the service code should imho qualify as persistent errors (if they are even allowed). CXF internal exceptions (xml/jaxb/validation errors) are indeed difficult, whether these may be recoverable at all heavily depends on the deployment so I agree this should be configurable. The same holds for RuntimeExceptions thrown by service code. Some implementations go with RuntimeException for rollback but this is still very broad. Imho, this behavior should also be configurable (per service if possible) plus there should be a custom exception type which always triggers rollback. - I tested the low level MessageListenerContainer I created with resource local and JTA transactions. JTA only seems to work if I use a polling approach. I am not sure if this is expected. I also ran into this with ActiveMQ, their consumer implementation does not allow this. I asked about this on activemq-users quite a while ago but got no response (http://mail-archives.apache.org/mod_mbox/activemq-users/201308.mbox/%3c5218d907.3070...@agno3.eu%3E). Client Side: - No special handling on conduit side - If the user uses a JCA Pooling Connection Factory the session would automatically take part in any user transactions. For one way messaging this is probably a good thing. For request reply this is rather not what we want as the message would only be sent after the commit. As the conduit waits for the reply the message then would never be sent out and we run into a timeout. Any chance to at least add something (callback?) that allows to commit and restart a transaction at the right point? With implementations closely following the spec, when using JTA the client session will forcibly (if you do not create a second non-transacted ConnectionFactory) be part of an active transaction (e.g. when calling a service inside another service) so this will be necessary. regards Moritz -- AgNO3 GmbH & Co. KG, Sitz Tübingen, Amtsgericht Stuttgart HRA 728731 Persönlich haftend: Metagesellschaft mbH, Sitz Tübingen, Amtsgericht Stuttgart HRB 744820, Vertreten durch Joachim Keltsch
JTA support for JMS Transport in CXF 3.0
Hi All, I am currently working on the transaction support (resource local and JTA) for the JMS transport in CXF 3. In a chat with Dan we found that it is not fully clear what we expect from the transaction support. So I will do a coarse design here on the list and hope to get some feedback on what you expect and would like to see. The general principle on kind of "container" managed transaction support is to open a transaction when a message is received. Then the message is processed inside the transaction. If an exception happens in the processing the transaction is rolled back and the JMS server tries some redeliveries. If these all fail the message goes to the dead letter queue. If the processing runs without an exception the transaction and so the message will be committed. Service side: - Support transactions only for One Way messaging. I think for request reply there is always a client on the other side who can retry when a message is lost and the client also wants some feedback about errors on the server side. - For one way exchanges I propose to roll back on any exceptions as it is the simplest case. We might also support to permanently fail a message on things like invalid xml as this will probably also fail the next time. It is difficult to correctly specify when to roll back and when to fail in this case. - I tested the low level MessageListenerContainer I created with resource local and JTA transactions. JTA only seems to work if I use a polling approach. I am not sure if this is expected. Client Side: - No special handling on conduit side - If the user uses a JCA Pooling Connection Factory the session would automatically take part in any user transactions. For one way messaging this is probably a good thing. For request reply this is rather not what we want as the message would only be sent after the commit. As the conduit waits for the reply the message then would never be sent out and we run into a timeout. I would be happy to hear from you what you would expect from transaction support and what you think about the ideas formulated here. If any of you has first hand experience with JMS transactions (especially JTA) I would also like to hear from your experiences. Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Secure CXF rsServer with Jaas authentication
Hi, I am newbie to CXF. I have configured CXF JAASAuthenticationFilter to authenticate by jaas realm to each rest call. But each time i had to pass Basic Authenticate header to authenticate it. Can i configure any token based login along with JAAS? So that only first time it authenticate with jaas and return any auth token. Next time only i need that auth token to make call from client side. This is my working blueprint http://www.w3.org/2001/XMLSchema-instance"; xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"; xmlns:camel="http://camel.apache.org/schema/blueprint"; xmlns:cxf="http://camel.apache.org/schema/blueprint/cxf"; xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.0.0"; xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs"; xsi:schemaLocation=" http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd http://camel.apache.org/schema/blueprint/cxf http://camel.apache.org/schema/blueprint/cxf/camel-cxf.xsd http://cxf.apache.org/blueprint/jaxrs http://cxf.apache.org/schemas/blueprint/jaxrs.xsd http://camel.apache.org/schema/blueprint http://camel.apache.org/schema/blueprint/camel-blueprint.xsd"; > http://localhost:80/v1"; /> < bean id="authorizationFilter" class="org.apache.cxf.jaxrs.security.JAASAuthenticationFilter"> Name of the JAAS Context http://camel.apache.org/schema/blueprint"; id="security"> -- View this message in context: http://cxf.547215.n5.nabble.com/Secure-CXF-rsServer-with-Jaas-authentication-tp5742659.html Sent from the cxf-dev mailing list archive at Nabble.com.
