In my springboot application when I can fortify to check vulnerabilities, I got some issues related to Locale Dependent Comparison . I have number of files where fortify shows to fix Locale Dependent Comparison issue.
I have 3 options to change:
I have to go and change all those files by using Locale.US like below.
from
switch (strngvariable.toLowerCase())
to
switch (strngvariable.toLowerCase(Locale.US))
During the spring Boot Initialization I can set the default locale as
public static void main(String[] args)
{
Locale.setDefault(new Locale("en","US"));
SpringApplication.run(OWDNApplication.class, args);
}
In the first REST call, set the default locale as
#GetMapping("/applogin")
public ResponseEntity getSignonDetails(#RequestParam("uname") String uname)
{
Locale.setDefault(new Locale("en","US"));
}
I know the first thing will work. I want to know will the 2 and 3 options work ? which would be the best choice.
I can try on my own and figure it out if by running Fortify scan on my eclipse. Unfortunately the fortify plugin is not showing me all the issues on my local.
I have to deploy onto server and run the software on server. this would be time consuming to test the changes.
Related
I have just received a new project, I have a fresh repo clone of a java spring project.
When I build it with Gradle, all the dependencies are downloaded but when one of the Gradle tasks execute, the unit tests, the build fails.
I think the problem resides in the argThat() method of Mockito that is not getting well integrated with JUnit. This is one of the places where the issue occurs:
Any time a unit tests have this kind of logic, it fails with:
The console output is not for the above test but it is a similar method with more complex logic.
The above tests still fail with the same issue.
This only happens in my machine and not on others that are on a Unix distribution, fedora.
I think the problem is due to the dependencies version, but I have tested with different ones to no avail.
I can give you more information if needed.
Thank you.
EDIT: Code - not a screenshot
#Test
void shouldAbortEventExecutionWhenJobFails() throws JobParametersInvalidException, JobExecutionAlreadyRunningException, JobRestartException, JobInstanceAlreadyCompleteException {
when(jobLauncher.run(eq(job1), argThat(jobParametersForPath(TEST_PATH_1)))).thenReturn(jobExecutionFailed);
when(job1.getName()).thenReturn("job1");
ExecutionState result = executor.execute(asList(event1, event2));
assertThat(result).isEqualTo(ExecutionState.FAILED);
verify(jobLauncher).run(eq(job1), argThat(jobParametersForPath(TEST_PATH_1)));
verify(jobLauncher, never()).run(eq(job2), argThat(jobParametersForPath(TEST_PATH_1)));
verify(jobLauncher).run(eq(job1), argThat(jobParametersForPath(TEST_PATH_2)));
verify(jobLauncher).run(eq(job2), argThat(jobParametersForPath(TEST_PATH_2)));
verifyNoMoreInteractions(jobLauncher);
}
private ArgumentMatcher<JobParameters> jobParametersForPath(String inputPath) {
return jobParameters ->
jobParameters.getParameters().get("inputFilePath").toString().equals(inputPath) &&
jobParameters.getParameters().get("outputFilePath").toString().equals(TEST_OUTPUT_PATH + "/" + inputPath) &&
jobParameters.getParameters().containsKey("timestamp");
}
I can't tell you the exact problem without inspecting your code or without reproducing your issue. But I guess the problem should be related to file paths;
I can see that there is a variable called outputFilePath inside your assertation object. in Linux environments, we use slash / for file paths, but in windows environments it's back-slashes \.
[1] https://www.howtogeek.com/181774/why-windows-uses-backslashes-and-everything-else-uses-forward-slashes/
[2] https://stackoverflow.com/a/1589959/3728639
You need to debug your Junit test and compare actual assertation object with the expected one
I am new to ActiveJDBC. I am trying to debug the sample project.
The code I want to debug is:
public static void main(String[] args) {
Base.open();
Person director = new Person("Stephen Spielberg");
director.saveIt();
//[break point here]
director.add(new Movie("Saving private Ryan", 1998));
director.add(new Movie("Jaws", 1982));
director.getAll(Movie.class).forEach(System.out::println);
Base.close();
}
The code compiles correctly and the instrumentation is properly executed (I believe) (have a look here).
The debugger is launched and paused at the defined break-point.
I am trying to evaluate the expression "Person.count()" and I am expecting the result to be 1.
But I have the following error in the 'Evaluate expression' window:
Method threw 'org.javalite.activejdbc.InitException' exception.
failed to determine Model class name, are you sure models have been instrumented?
Have a look: https://unsee.cc/nipareto/
It is possible that you recompiled models after instrumentation unintentionally. If you instrument, then make any change to a model, and then try to run your code, and IDE will detect the change and recompile your model, thus blowing away instrumentation.
Ensure you instrument before you run your code.
Additionally, the link you provided: https://github.com/javalite/activeweb-simple is not corresponding to code. I think you are using this one: https://github.com/javalite/simple-example. If so, try running on command line according to README.
Debugging models in ActiveJDBC in IDEA is what I do daily:)
Also, I recommend you watch the video on this page: http://javalite.io/instrumentation because it walk you step by step using IDEA.
UPDATE April 10 2017:
I recorded this video to show you how to instrument and debug an ActiveJDBC project: https://www.youtube.com/watch?v=2OeufCH-S4M
I have to apply toUpperCase on a name that may contain accents ("é", "à", etc.).
Problem:
with JUnit, "é".toUpperCase converts to "E", the accent is removed
in my application (a Spring REST API), "é".toUpperCase converts to "É". The input comes from an Ember frontend, but the encoding is the same (UTF-8)
JUnit tests and Spring application use the same characters set (UTF-8) and the locale is French. Both running on Oracle Java 8, on the same machine (Jenkins CI on Debian, but I can reproduce this behavior on my computer: Windows 7).
I tried to specify the locale toUpperCase(Locale.FRANCE), but it doesn't solve my problem.
Are you aware of something that may explain this difference?
As in the conversation with #JonathanLermitage this is not a Java problem but is related to the embedded database (h2) used in the unit tests that is not correctly configured.
I'm using Java 8, no particular configuration.
#Test
public void test()
{
String a = "àòùìèé";
String b = a.toUpperCase();
System.out.println(b);
System.out.println(Locale.getDefault());
assertEquals(b,"ÀÒÙÌÈÉ");
}
Returns
ÀÒÙÌÈÉ
en_US
I had the same problem once and it was fixed for me by setting the default Locale:
Locale.setDefault(new Locale("fr_FR"));
Recently got the code to write bdd tests with cucumber on Java. There is already maven project with couple of tests and test framework. I need to continue writing bdd tests using this framework.
I am writing API tests and try to run them and i get the error. I found where it fails to run further but I want to figure out what's the idea of doing so in the code. Let me share some code:
So the test framework is collecting info about the API host name this way:
public class AnyClass {
private static final String API_HOSTNAME = "hostname";
private static String getAPIHostName() {
String apiHostName = System.getProperty(API_HOSTNAME);
...
}
When i leave it as is, and run the test, i get the error that host name is empty.
Can you advise on what might be expected to have under System property key "hostname"?
p.s. I tried to use http://localhost and http://127.0.0.1, where my api is located instead of assigning system property but it cannot find such host name.
Can you advise on what might be expected to have under System property key "hostname"?
Yes, I needed to run tests in command line with the syntax like:
mvn clean verify -Dhostname=http://127.0.0.1:8080
I am developing a Java program in eclipse using a proprietary API and it throws the following exception at run-time:
java.io.UnsupportedEncodingException:
at java.lang.StringCoding.encode(StringCoding.java:287)
at java.lang.String.getBytes(String.java:954)...
my code:
private static String SERVER = "localhost";
private static int PORT = 80;
private static String DFT="";
private static String USER = "xx";
private static String pwd = "xx";
public static void main(String[] args) {
LLValue entInfo = new LLValue();
LLSession session = new LLSession(SERVER, PORT, DFT, USER, pwd);
try {
LAPI_DOCUMENTS doc = new LAPI_DOCUMENTS(session);
doc.AccessPersonalWS(entInfo);
} catch (Exception e) {
e.printStackTrace();
}
}
The session appears to open with no errors, but the encoding exception is thrown at doc.AccessEnterpriseWS(entInfo)
Through researching this error I have tried using the -encoding option of the compiler, changing the encoding of my editor, etc.
My questions are:
how can I find out the encoding of the .class files I am trying to use?
should I be matching the encoding of my new program to the encoding of the API?
If java is machine independent why isn't there standard encoding?
I have read this stack trace and this guide already --
Any suggestions will be appreciated!
Cheers
Run it in your debugger with a breakpoint on String.getBytes() or StringCoding.encode(). Both are classes in the JDK so you have access to them and should be able to see what the third party is passing in.
The character encoding is used to specify how to interpret the raw binary. The default encoding on English Windows systems in CP1252. Other languages and systems may use different a different default encoding. As a quick test, you might try specifying UTF-8 to see if the problem magically disappears.
As noted in this question, the JVM uses the default encoding of the OS, although you can override this default.
Without knowing more about the third party API you are trying to use, it's hard to say what encoding they might be using. Unfortunately from looking at the implementation of StringCoding.encode() it appears there are a couple different ways you could get an UnsupportedEncodingException. Stepping through with a debugger should help narrow things down.
It looks to me as if something in the proprietary API is calling String.getBytes with an empty string for the character set.
I compiled the following class
public class Test2 {
public static void main(String[] args) throws Exception {
"test".getBytes("");
}
}
and when I ran it, I got the following stacktrace:
Exception in thread "main" java.io.UnsupportedEncodingException:
at java.lang.StringCoding.encode(StringCoding.java:286)
at java.lang.String.getBytes(String.java:954)
at Test2.main(Test2.java:3)
I would be surprised if this is anything to do with the encoding in which the class files are written. It looks to me like this is a problem with code, not a problem you can fix by changing file encodings or compiler/JVM switches.
I don't know anything about what this proprietary API is supposed to do or how it works. Perhaps it is expecting to be run inside a Java EE or web application container? Perhaps it has a bug? Perhaps it needs more configuration before it can run without throwing exceptions? Given that it's proprietary, can you get any support from the vendor?