In the class org.apache.camel.component.cxf.feature.PayLoadDataFormatFeature, allowStreaming is enabled by default. This will set the MessagePart type to DOMSource or Source by default for PAYLOAD mode.
static {
String s = System.getProperty("org.apache.camel.component.cxf.streaming");
DEFAULT_ALLOW_STREAMING = s == null || Boolean.parseBoolean(s);
}
boolean allowStreaming = DEFAULT_ALLOW_STREAMING;
So it looks like to turn off this behavior, allowStreaming=false should be explicitly set on the CxfEndpoint. Just want to know if this is by design? Thanks in advance.
Yes, you can use allowStreaming option to override the default setting.
Related
Is there any environment variable or something how to change the maxVarCharLength like tablePrefix in JobRepositoryFactoryBean.java?
I couldn't find any config class where this setter method is called
public void setMaxVarCharLength(int maxVarCharLength) {
this.maxVarCharLength = maxVarCharLength;
}
It is up to you to call this method in order to set the maxVarCharLength property. The JobRepositoryFactoryBean will then use the value you set to create the JobRepository. You can find an example here: https://docs.spring.io/spring-batch/4.0.x/reference/html/job.html#configuringJobRepository
I would like to use Typesafe's Config in my project but I don't want any passwords in clear text in any file on the file system of any integration or production server. Also, I do not want to use environment variables to store clear text passwords.
Ideally, I would like a solution similar to the Jasypt EncryptablePropertyPlaceholderConfigurer available for Spring that would allow me to designate some property values as being encrypted and have the config system automatically decrypt them before handing the value down to the application. I'd like to use the JCE keystore to store the key and pass it into my app, but I'm also open to other tools that use a database to store keys.
Has anyone managed to get the Typesafe Config project to work this way?
Update: sourcedelica was completely correct to criticize the solution that relied on passing the key as an environment variable. I changed my question to request a solution that uses a more secure way of handling keys.
You could try pimping the typesafe Config class like so:
object ConfigPimping{
implicit class RichConfig(conf:Config){
def getPasswordString(path:String, encryptKey:String):String = {
val encrypted = conf.getString(path)
val decrypted = ... //do decripy logic of your choice here
decrypted
}
}
}
object ConfigTest{
import ConfigPimping._
def main(args: Array[String]) {
val conf = ConfigFactory.load()
val myPass = conf.getPasswordString("myPass", "myDecryptKey")
}
}
Then, as long as the RichConfig is always imported and available, you can get access to your custom decrpyt logic for passwords via the getPasswordString function.
If you are happy to pass the encryption key as an environment variable then instead you could pass all of the sensitive properties as environment variables and not worry about using encryption directly with the Typesafe config library.
For example:
my.sensitive = ${FOO_ENV}
You said that you do not want to use environment variables to store clear text passwords, but if you are storing your encryption key in an environment variable it is the equivalent.
Alternatively you could use a system property instead of an environment variable. For example, when starting your app, use -Dmy.sensitive=xxx.
If you do end up getting encrypted values into your configuration then you could use a wrapper class to that would do the decryption. I use a wrapper class to add methods like optString to Config. You could add a method like decryptString.
For a discussion on securing keys to be used in production see my question: Securing passwords in production environment.
I chose the path that cmbaxter suggested. I'm putting the example code here because comments don't seem to support code.
I added some special syntax, to the config file, so if I want to put an encrypted password in my config file I do it like this:
my-app-config{
db-username="foo"
db-password="ENC(9yYqENpuCkkL6gpoVh7a11l1IFgZ0LovX2MBF9jn3+VD0divs8TLRA==)"
}
Note the "ENC()" wrapper around the encrypted password.
Then I made a config factory that returns a DycryptingConfig object instead of the typesafe config:
import rzrelyea.config.crypto.DecryptingConfig;
import rzrelyea.config.crypto.KeyProvider;
public class ConfigFactory{
public static final Config makeDecryptingConfig(com.typesafe.config.Config config, KeyProvider keyProvider){
return new DecryptingConfig(config, keyProvider);
}
}
And here's the code for the DecryptingConfig:
import java.security.Key;
import static rzrelyea.config.Validators.require;
public class DecryptingConfig extends rzrelyae.config.Config {
private final com.typesafe.config.Config config;
private final Decryptor decryptor;
public DecryptingConfig(com.typesafe.config.Config config, KeyProvider keyProvider){
super(config);
require(keyProvider, "You must initialize DecryptingConfig with a non-null keyProvider");
this.config = config;
final Key key = keyProvider.getKey();
require(key, "KeyProvider must provide a non-null key");
decryptor = new Decryptor(config.getString("crypto-algorithm"), key, config.getString("encoding-charset"));
}
#Override
public String getString(String s) {
final String raw = config.getString(s);
if (EncryptedPropertyUtil.isEncryptedValue(raw)){
return decryptor.decrypt(EncryptedPropertyUtil.getInnerEncryptedValue(raw));
}
return raw;
}
Obviously, you'd need to implement your own rzrelyea.config.Config object, your own EncryptedPropertyUtil, your own Decryptor, and your own KeyProvider. My implementation of rzrelya.config.Config takes a typesafe config object as a constructor parameter and forwards all calls to it. LOTS of boiler plate code in it! But I thought it was better to forward calls to an interface rather than to extend com.typesafe.config.impl.SimpleConfig. You know, prefer composition to inheritance and code to interfaces, not implementations. You may choose a different route.
At the risk of telling you something you already know...
Never store a password -- store and compare against a hash instead
Use Bcrypt for password hashes -- it's slow which is good for guarding against a brute-force attack
Use a salt -- to guard against a rainbow table style attack
Use SSL (https) -- to prevent passwords from being seen in the clear
Here is an example that uses the Mindrot jBCrypt library:
def PasswordHash( name:String, pwd:String, version:Int = 1 ) : String = {
if( version == 2 && false )
{
// ANY CHANGES SHOULD BE MADE AS A NEW VERSION AND ADDED HERE
""
}
else
{
import org.mindrot.jbcrypt.BCrypt // jbcrypt-0.3m.jar
// Salt will be incorporated in the password hash
val salt = BCrypt.gensalt(12) // Default is 10, or 2**10 rounds. More rounds is slower.
BCrypt.hashpw( (name + pwd), salt )
}
}
def VerifyPassword( name:String, pwd:String, hash:String, version:Int = 1 ) : Boolean = {
if( version == 1 )
{
import org.mindrot.jbcrypt.BCrypt // jbcrypt-0.3m.jar
BCrypt.checkpw( (name + pwd), hash )
}
else
false
}
> PasswordHash( "johnny", "mypassword" )
res4: String = $2a$12$dHIlTL14.t37Egf7DqG4qePE446GzzhIUAVuewMfkhfK0xxw3NW6i
> VerifyPassword( "johnny", "mypassword", "$2a$12$dHIlTL14.t37Egf7DqG4qePE446GzzhIUAVuewMfkhfK0xxw3NW6i" )
res5: Boolean = true
> VerifyPassword( "johnny", "mommiespassword", "$2a$12$dHIlTL14.t37Egf7DqG4qePE446GzzhIUAVuewMfkhfK0xxw3NW6i" )
res6: Boolean = false
For what you are trying to do, I presume you would store the "name", "password hash", and "hash version" in your configuration.
Is it bad practice to change my getter method like version 2 in my class.
Version 1:
public String getMyValue(){
return this.myValue
}
Version 2:
public String getMyValue(){
if(this.myValue == null || this.myValue.isEmpty()){
this.myValue = "N/A";
}
return this.myValue;
}
I think it is actually quite a bad practice if your getter methods change the internal state of the object.
To achieve the same I would suggest just returning the "N/A".
Generally speaking this internal field might be used in other places (internally) for which you don't need to use the getter method. So in the end, the call to foo.getMyValue() could actually change the behaviour of foo.
Alternatively, the translation from null to "N/A" could be done in the setter, i.e. the internal value could be set to "N/A" if null is passed.
A general remark:
I would only add states such as "N/A" if they are expected by some API or other instance relying on your code. If that is not the case you should rely on the standard null types that are available to you in your programming language.
In my opinion, unless you are doing lazy-loading (which you are not in that case), getters should not change the value. So I would either:
Put the change in the setter
public void setMyValue(String value) {
if(value == null || value.isEmpty()){
this.myValue = "N/A";
} else {
this.myValue = value;
}
}
Or make the getter return a default value if value not set properly:
public String getMyValue() {
if(this.myvalue == null || this.myvalue.isEmpty()){
return "N/A";
}
return this.myValue;
}
In the case of lazy-loading, where I would say that changing your members in a getter is fine, you would do something like:
public String getMyValue() {
if (this.myvalue == null) {
this.myvalue = loadMyValue();
}
return this.myValue;
}
No. You're doing two things here. Getting and setting.
Yes. It's a bad practice.
Why?
When the value is set (in a constructor or setter method), it should be validated, not when a getter method is called. Creating a private validate* method for this is also a good idea.
private boolean validateThisValue(String a) {
return this.myValue != null && !this.myValue.isEmpty();
}
public void setThisValue(String a) {
if (validateThisValue(a)) {
this.myValue = a;
}
else {
// do something else
// in this example will be
this.myValue = "N/A";
}
}
And, in the getter method, never ever change the state of the object. I have worked on some projects, and the getter often must be made const: "this method cannot change internal state".
At least, if you do not want to complicate things, in the getter method, you should return "N/A" rather than change internal state and set myValue to "N/A".
I usually define a specific getter.
Never alter original getter:
public String getMyValue(){
return this.myValue
}
And create a specific getter:
public String getMyValueFormatted(){
if(this.myvalue == null || this.myvalue.isEmpty()){
return "N/A";
}else{
return this.myValue;
}
}
I think it's better to initialize this.myValue = "N/A". And subsequent calls to setMyValue should modify the this.myValue according to your business conditions.
The getMyValue shouldn't modify in any way this.myValue. If your needs are to return a certain value, you should return that value (like "N/A") and not alter this.myValue . Getters must not modify member's value.
I would change better the setter method so, if the value is null or empty, the N/A is assigned to the attribute. So, if you use the attribute in other methods inside the class (v.g. toString()) you will have the intended value there.
Alternatively, change the setter method to launch an exception when the value being set is not right, so the programmer is forced to improve its handling prior to setting the value.
Other than that, it is ok.
I do feel this is a bad practice unless and until you explain the reason why it is so necessary for you modify the object inside the getter method instead of doing it inside the setter method.
Do you feel this cannot be done for some reason? Could you please elaborate?
Do what ever you like. After all getters and setters are just another public methods. You could use any other names.
But if you use frameworks like Spring, you are bound to use those standard names and you should never put your custom codes inside them.
absolutely yes, it's a bad pratice.
Imagine you communicate accross network with a third party (remoting, COM, ...), this will increase the round-trip and then hit application performance.
A setter could modify as part of validation, but a getter should return the value and let the validation be done by the caller. If you do validate, then how should be documented.
This actually highly depends on the contract you want to enforce with your get()-method. According to design-by-contract conventions the caller has to make sure that the preconditions are met (which means doing a validation in a setter method often is actually bad design) and the callee (I do not know if that's the correct english term for that, i.e., the called one) makes sure that the post conditions are met.
If you define your contract so that the get()-method is not allowed to change the object then you are breaking your own contract. Think about implementing a method like
public isValid() {
return (this.myvalue == null || this.myvalue.isEmpty());
}
Advantage of this approach is that you do not have to check wether the return of your get() is "N/A" or something else. This also can be called before calling set() to validate that you do not insert illegal values into your object.
If you want to set a default value you should do that during initialization.
State changes in getters should be a hanging offence. It means that client code must be careful about the order in which it accesses getters and setters and to do this it must have knowledge of the implementation. You should be able to call the getters in any order and still get the same results. A related problem occurs when the setter modifies the incoming value depending on the current state of the object.
You can use some value holder for this purpose. Like Optional class in guava library.
I am using rich faces select component.
I want dynamic values when user manually type some thing in the select component.
<rich:select enableManualInput="true" defaultLabel="start typing for select" value="#{supplierSearchBean.userInput}">
<a4j:ajax event="keyup" execute="#this" listener="#{supplierSearchBean.userInputChange}"/>
<f:selectItems value="#{supplierSearchBean.selectOptions}" />
</rich:select>
Java code as follows
public void userInputChange(ActionEvent ae){
Map map = ae.getComponent().getAttributes();
System.out.println(map.toString());
}
public void setUserInput(String userInput) {
System.out.println("userINput = " + userInput);
this.userInput = userInput;
}
Here i found 2 issues
1st: setUserINput always print empty string when user type value
2nd: listener method never get call.
any help ?
The problem is most probably that there is no selected value while the user types, and this component restricts the allowed values to the specified select items. A partial input is thus not valid and cannot be bound to your bean.
I think you could get the expected behavior if you use a rich:autocomplete instead. However, if you want to restrict the allowed values, maybe you can keep your rich:select and listen for the selectitem event.
Override getItems function in richfaces-utils.js file in richfaces-core-impl-4.0.0.Final.jar under richfaces-core-impl-4.0.0.Final\META-INF\resources folder.
Change the condition of pushing items to be
if(p != -1)
instead of
if(p == 0)
This should fix the issue.
How do I use UriPathExtensionMapping in MVC4? I've added the mapping in the formatter such that:
MediaTypeMappings.Add(new UriPathExtensionMapping("json", new MediaTypeHeaderValue("application/json"))
But I can't use the extension on my route unless I add a verb, such as:
routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}.{extension}"
);
Then it'll recognize my desired media type, but it also starts expecting "extension" as a parameter on the action. Example:
public object Get(string extension)
{
}
Instead of just:
public object Get()
{
}
How can I resolve this?
Thanks!
I don't remember if I noticed this problem, but it might be because I explicitly specified the default value for the extension like:
var rF = routes.MapHttpRoute(
name: "DefaultApi.v1.format",
routeTemplate: "api/1/{controller}/{action}.{format}/{*id}",
defaults: new { id = RouteParameter.Optional, format = "json", version = 1 }
);
*note format = "json" in the line beginning with defaults.
I did also notice that this sometimes doesn't work on requests with trailing parameters for id, like ~/api/1/values/get.json/4.
I can't repro this problem.
You are right that, to use UriPathExtensionMapping, you will need to specify the {controller}.{ext} in your route, like what you described above. If you only specify the {controller}, and uri looks like ~/home.json, then the controller token will be mapped to home.json, which is probably not what you wanted.
However, you should not need to require an "extension" parameter in your action. If you continue seeing this problem, can you post your entire repro, including your controller, your routes and configuration set up with custom formatter? thank you.