Currently I'm involved in a project for implementing security code reviews for Workfusion bots. Workfusion can handle a mix of Java and Groovy code embedded in XML files or standalone code.
My team is trying to assess if it's possible to use any free/opensource Static Application Security Tool for it. I'm currently exploring the posiblity of creating a plugin for Spotbugs.
I was able to run reviews successfully with Java code + Maven with Spotbugs and FindSecBugs plugins, but I haven't figured out how to extend Spotbugs in order to parse the XML files, extract the embedded Groovy scripts and analyze them.
Do you know any static application security tool for Workfusion or could suggest any approach to extend any other SAST tool?
The main requirement for Find Security Bugs to work is the ability to compile the code.
If you have access to the class files, FindSecurityBugs should work. If the code is evaluate at runtime, you'll need to compile the snippet which is not an easy task if the script have access to a special context with initialized objects.
Related
At the moment, I'm using two different frameworks for REST APIs integration testing, and load/stress testing. Respectively : geb (or cucumber) and gatling. But most of the time, I'm re-writing some pieces of code in load / performance scenarii that I've been writing for integration testing.
So the question is : is there a framework (running on the JVM) or simply a way, to write integration tests (for a strict REST API use case), preferably programmatically, then assemble load testing scenarios using these integration tests.
I've read cucumber maybe could do that, but I'm lacking a proper example.
The requirements :
write integration tests programmatically
for any integration test, have the ability to "extract" values (the same way gatling can extract json paths for instance)
assemble the integration tests in a load test scenario
If anyone has some experience to share, I'd be happy to read any blog article, GitHub repository, or whatever source dealing with such an approach.
Thanks in advance for your help.
It sounds like you want to extract a library that you use both for your integration tests as well as your load test.
Both tools you are referring to are able to use external jar.
Suppose that you use Maven or Gradle as build tool, create a new module that you refer to from both your integration tests and your load tests. Place all interaction logic in this new module. This should allow you to reuse the code you need.
I am currently working in a WEB Java project and I have the following requirement: I have to make sure our customers don't have access to the packaged files in order to change them. Actually, I'd like to do that with only a few of those classes but without using any obfuscators due to the size of my project and the resources it uses to accomplish some tasks (reflection, annotations, interceptors, etc).
Does anybody have any tips?
Thanks,
Luan
So I'm confused about the process/steps to keep automated tests in sync with gherkin/feature files in specflow. Assuming the feature files are written in gherkin and checked into git source control.
I see that there is a tool to generate stub automated tests from a gherkin file, and that flows naturally into letting a developer implement those tests.
My question is if the features and spec change, what is the workflow for refactoring or updating those tests to keep it in sync? Is it done manually by the developer, or does specflow or other BDD driven tools have something to help you manage the refactoring of the test files?
There is no tool support that will update the steps when the wanted behavior changes.
The steps that are used for automating the specifications has to be maintained manually in the same way as the steps was implemented when they where new.
Anyone capable of implementing the code used in the automation has to do it. This may be a developer, a tester or someone else with sufficient knowledge about the domain and programming.
i'm newbie in JHipster and i'm trying to figure this, when i create a new entity JHipster generates several files, angular, html and java classes, now if i want a common code for all this generated code i must edit each time that i use the yeoman generator? what i want is:
Custom Index template, and pages, is secure to edit them?.
Customize the entity tables, entity forms using angular, maybe extending yeoman generators
Customize generate java classes, maybe i think using AOP
So i need to edit each time for each generated code? and is a good practice this or what i want? for clarify more i want to use a Custom Bootstrap/angular Dashboard template like Minovate, i see how to customize bootstrap in the documentation but not about what i'm asking for, Thanks.
JHipster is just a code generator, once generated the code is yours.
For angular screens I would say do as much as you can in CSS/SASS.
But it's very likely that you will need to build some screen mixing several entities and change the structure of entity screens.
So you should rather consider them as a starting point and do your own stuff in another folder so that it does not get overwritten by next re-generations.
This way you can still update your entity definitions in .jhipster folder and re-run yo jhispter:entity <entity name> on the entities you modified.
Customising java Entities is usually much simpler and you can easiliy achieve this by merging generated code with git and defining your service classes.
AOP seems overkill here.
Extending a yeoman generator is a lot of work.
I suggest to use some VSC (git, subversion or whatever you like) have a branch dedicated to plain jhipster generated code and another one where you make customization.
Eventually regenerate on jhipster branch and merge back on yours.
You should at least reduce manual intervention.
I want to package a Groovy CLI application in a form that's easy to distribute, similar to what Java does with JARs. I haven't been able to find anything that seems to be able to do this. I've found a couple of things like this that are intended for one-off scripts, but nothing that can compile an entire Groovy application made up of a lot of separate Groovy files and resource data.
I don't necessarily need to have the Groovy standalone executable be a part of it (though that would be nice), and this is not a library intended to be used by other JVM languages. All I want is a simply packaged version of my application.
EDIT:
Based on the couple of responses I got, I don't think I was being clear enough on my goal. What I'm looking for is basically a archive format that Groovy can support. The goal here is to make this easier to distribute. Right now, the best way is to ZIP it up, have the user unzip it, and then modify a batch/shell file to start it. I was hoping to find a way to make this more like an executable JAR file, where the user just has to run a single file.
I know that Groovy compiles down to JVM-compatible byte-code, but I'm not trying to get this to run as Java code. I'm doing some dynamic addition of Groovy classes at runtime based on the user's configuration and Java won't be able to handle that. As I said in the original post, having the Groovy executable is included in the archive is kind of a nice-to-have. However, I do actually need Groovy to be executable that runs, not Java.
The Gradle Cookbook shows how to make a "fat jar" from a groovy project: http://wiki.gradle.org/display/GRADLE/Cookbook#Cookbook-Creatingafatjar
This bundles up all the dependencies, including groovy. The resulting jar file can be run on the command line like:
java -jar myapp.jar
I've had a lot of success using a combination of the eclipse Fat Jar plugin and Yet Another Java Service Wrapper.
Essentially this becomes a 'Java' problem not a groovy problem. Fat Jar is painless to use. It might take you a couple of tries to get your single jar right, but once all the dependencies are flattened into a single jar you are now off an running it at the command line with
java -jar application.jar
I then wrap these jars as a service. I often develop standalone groovy based services that perform some task. I set it up as a service on Windows server using Yet Another Java Service and schedule it using various techniques to interact with Windows services.