I use twitter4j+ camel plugin to read the tweets
<route id="twitter-timeline-incoming">
<from
uri="twitter://timeline/user?type=polling&delay=180&consumerKey=xxxx&consumerSecret=xxxx&accessToken=xxxx8&accessTokenSecret=xxxxg&user=user_account" />
<process ref="setTwitterTimestampProcessor" />
<filter>
<method ref="twitterFeedFilter" />
<to uri="direct:twitterProcessFeed" />
</filter>
</route>
Twitter has made it mandatory to use SSL from today, https://dev.twitter.com/discussions/24239
I would like to know how to enable SSL for these requests , which is not given in here
http://camel.apache.org/twitter.html.
Thanks.
On Jan 14 2014 Twitter updated it's API to require all endpoints be https. The default API endpoints in Twitter4J are http, rather than https. You can change them manually for now, until they update the defaults in Twitter4J:
ConfigurationBuilder confBuilder=new ConfigurationBuilder();
confBuilder.setOAuthConsumerKey(consumerKey);
confBuilder.setOAuthConsumerSecret(consumerSecret);
confBuilder.setHttpRetryCount(3);
confBuilder.setHttpRetryIntervalSeconds(30);
confBuilder.setRestBaseURL("https://api.twitter.com/1.1/");
confBuilder.setStreamBaseURL("https://stream.twitter.com/1.1/");
confBuilder.setSiteStreamBaseURL("https://sitestream.twitter.com/1.1/");
confBuilder.setUserStreamBaseURL("https://userstream.twitter.com/1.1/");
confBuilder.setOAuthRequestTokenURL("https://api.twitter.com/oauth/request_token");
confBuilder.setOAuthAccessTokenURL("https://api.twitter.com/oauth/access_token");
confBuilder.setOAuthAuthorizationURL("https://api.twitter.com/oauth/authorize");
confBuilder.setOAuthAuthenticationURL("https://api.twitter.com/oauth/authenticate");
Configuration conf=confBuilder.build();
Twitter twitter=new TwitterFactory(conf).getInstance();
you can pass parameter to JVM to turn on SSL:
-Dtwitter4j.http.useSSL=true
At least this solved my issue.
Setting JVM is not an option for me,
Ticket has been raised in camel + twitter plugin
https://issues.apache.org/jira/browse/CAMEL-7134 and seems a patch is available in fix versions 2.11.4, 2.12.3, 2.13.0
Related
I would like to have the ability to switch listener configuration easily in Mule (CE-3.6.1) from http to https (with basic autentication). I've created a variable in the mule-project.xml 'mule.protocol' and two properties files http.properties and https.properties with some data like port (the same port in http and https), host, password, etc.
in config.xml I have:
<context:property-placeholder location="${mule.protocol}.properties" />
<http:listener-config name="HTTP_Listener_Configuration" host="${host}" port="${port}" doc:name="HTTP Listener Configuration" protocol="${protocol}">
<tls:context>
<tls:key-store type="${keystore.type}" path="${keystore.path}" keyPassword="${keystore.keyPassword}" password="${keystore.password}" />
</tls:context>
</http:listener-config>
but I have two problems.
First, I get a message: Value '${protocol}' is not man-valid with respect to enumeration '[HTTP, HTTPS]'
and the second, section 'tls:context' is permitted only in https case, so I would have to hide it dynamically. How to solve these problems or whether there is another way to easily switch between the configuration of http and https? I'm using HTTP_Listener_Configuration in many services.
Unfortunately, this was only added for Mule 3.8.0 (coming soon). In older versions the protocol attribute does not support properties. You could use a Spring profile as a workaround. You can find more data in the JIRA ticket for this.
I have the following requirement. Please advise on how to set up the proxies.xml properly.
localhost/... user authentication is required from root level down (basically user needs to be authenticated once to access the whole website, which includes the 2 subsystems below)
localhost/subsys1/... all requests under this url should go to host1:8081
localhost/subsys2/... all requests under this url should go to host2:8082
I tried to set up the proxies.xml this way, but it doesn't seem to work.
<router>
<serviceProxy port="80">
<path>/</path>
<basicAuthentication>
<user name="guest" password="guest"/>
</basicAuthentication>
</serviceProxy>
<serviceProxy port="80">
<path>/subsys1</path>
<target host="host1" port="8081"/>
</serviceProxy>
<serviceProxy port="80">
<path>/subsys2</path>
<target host="host2" port="8082"/>
</serviceProxy>
</router>
Thanks,
Denny
I think the basic auth should be placed on the two proxied service as it will do the auth part.If u are trying to do it globally i havent tried it that way and i am not sure that it can be configured as such.
http://www.membrane-soa.org/service-proxy-doc/4.2/interceptors/examples.htm .What i also found usefull is that membrane service proxy is built on spring :-)
I'm trying to enable an application to use Client-Auth security with spring. Here's my configuration:
<security:http pattern="/api/**" >
<security:x509 subject-principal-regex="CN=(.*?),"
user-service-ref="x509UserService" />
<security:intercept-url pattern="/api/**" access="IS_AUTHENTICATED_FULLY" requires-channel="https" />
</security:http>
If I don't configure anything within web.xml or tomcat's server.xml, the browser is never prompted to send along a certificate with the request. Consequently, it always return null in in org.springframework.security.web.authentication.preauth.x509.X509AuthenticationFilter.extractClientCertificate(HttpServletRequest) method.
Is there something special that needs to be configured to have Spring participate in the SSL flow and request the client certificate?
Any help would be appreciated.
If I specify clientAuth='want' in the server.xml connector configuration, this has the undesirable side-effect of prompting everyone for certificates regardless of if they're accessing the /api path.
Similarly, if I specify the login-config and auth-method to be CLIENT-CERT, it also challenges the user, but then I would basically have to duplicate all of the cert checking I'd be doing in spring (or so it would seem).
Depending on your current java and build variety, at the very minimum you would either need to include something similar to the
<filter>
<filter-name>springSecurityFilterChain</filter-name>
<filter-class>
org.springframework.web.filter.DelegatingFilterProxy
</filter-class>
</filter>
<filter-mapping>
<filter-name>springSecurityFilterChain</filter-name>
<url-pattern>/api/*</url-pattern>
</filter-mapping>
or if you're using Java configuration with spring...
public class SecurityWebApplicationInitializer
extends AbstractSecurityWebApplicationInitializer {
}
I have a Mule application which needs to talk an external server over HTTPS using 2 way SSL authentication.
My question is: How to enable Server Certificate verification in Mule ? It seems, by default Mule doesn't verify Server's Cert. I am using Mule v 3.3.0.
For example: '-k' option in curl disables server's cert verification.
In similar way, is there any configuration parameter by which I can enable/disable Server's cert verification ?
Thanks
Jai
For Mule versions before 3.6, the HTTP transport supports configuration of the trust store used by the HTTP outbound endpoint to determine whether the certificate presented by an HTTPS server should be trusted.
To provide a key store that contains the certificates of servers you need to trust, provide the <https:tls-server /> to the <https:connector />, and reference that connector in your <https:outbound-endpoint />:
<https:connector name="myHttpsConnector">
<https:tls-server path="truststore.jks" storePassword="supersecure" />
</https:connector>
<flow name="someFlow">
<https:outbound-endpoint host="remote-host" port="443" path="/api" connector-ref="myHttpsConnector" />
</flow>
The blog post linked in clare's answer explains this a bit, from both the server side and the client side. You can also refer to the HTTPS Transport Reference, although it doesn't explain the use of tls-server vs. tls-client.
You can check out this blogpost. It will show you how you can configure mutual authentication in Mule. HTH.
You can configure the HTTP Request connector in Mule >= 3.6.0 to use a trust store you create that contains the certificate(s) of the server(s) you need to trust using TLS Configuration.
It might look something like this:
<tls:context name="tlsContextForServiceFoo">
<tls:trust-store path="serviceFooServerCertificates.jks" password="supersecure"/>
<tls:key-store path="myClientCertificates.jks" keyPassword="extrasecure" password="ultrasecure"/>
</tls:context>
<http:request-config name="twoWayAuthServiceFooConfig"
protocol="HTTPS"
host="services.pentagon.gov"
port="443"
tlsContext-ref="tlsContextForServiceFoo" />
<flow name="useServiceFoo">
<http:request config-ref="twoWayAuthServiceFooConfig" path="/api/doStuff" method="POST" />
</flow>
By following https://activemq.apache.org/rest.html, I'm able to push messages via the REST API (e.g. curl -u admin:admin -d "body=message" http://localhost:8161/api/message/TEST?type=queue works, and I can see in the admin console) However, I'd like to be able to use HTTPS. I found https://activemq.apache.org/http-and-https-transports-reference.html and http://troyjsd.blogspot.co.uk/2013/06/activemq-https.html but couldn't manage to make it work. Based on these two outdated/incomplete links:
I added to conf/activemq.xml
Imported self-signed certificate into JDK keystore (per http://troyjsd.blogspot.co.uk/2013/06/activemq-https.html)
Copied xstream and httpclient jars from lib/optional to lib/ (both under ActiveMQ directory, obviously)
So,
How can I set ActiveMQ so that it can be used with a HTTPS REST endpoint?
Assuming I did step 1, how can I test it (a similar curl command example like the above)?
I use ActiveMQ 5.9.1 and Mac OS 10.9.4
Uncomment the following section of conf/jetty.xml.
<!--
Enable this connector if you wish to use https with web console
-->
<!--
<bean id="SecureConnector" class="org.eclipse.jetty.server.ssl.SslSelectChannelConnector">
<property name="port" value="8162" />
<property name="keystore" value="file:${activemq.conf}/broker.ks" />
<property name="password" value="password" />
</bean>
-->
Jetty powers not only the WebConsole, but all HTTP stuff in ActiveMQ.
It should work out of the box for testing, but you probably want to roll your own keystore/certificate for real use.
You could use curl as before on port 8162 with HTTPS given you supply the "insecure" flag -k.
Otherwise, you need to create a trust store in pem format and supply it - see this SO for details. Curl accept the argument --cacert <filename.pem> with your certificate or issuing CA in it.