When deploying a Corda 4.0 CorDapp to UAT, must the Jar be signed?
We have tried using devMode = true - which causes the node to recognize the flows in the CorDapp, but when we set devMode to false it seems the node is unable to recognize the CorDapp.
This could be because the JAR has been signed using the default development key. This is the case when devMode is set to true in your build.gradle.
If this is the case you need to add cordappSignerKeyFingerprintBlacklist=[] to the node.conf. If devMode=false, the Corda development key is blacklisted as it's completely insecure. This is suitable for PoC purposes only, NOT PRODUCTION.
The correct fix is to sign the app with a your 'own' key.
You can also switch off Jar signing when building the CorDapp by setting cordapp { signing { enabled false } } in the build.gradle, which should cause it not to be signed.
More information can be found here: https://docs.corda.net/cordapp-build-systems.html#signing-the-cordapp-jar
Related
I've observed the following behavior when I generate a new application using JHipster:
When I just call jhipster, it shows a set of prompts to make my choices.
When I call jhipster jdl <myjslfile.jdl>:
2.1. If the JDL has just entities, not declaring a config application section, I've got an error: Database type is required to validate entities.
2.2. If the JDL has the minimum config application like the following, it assumes some defaults and does not show any prompt.
I'm trying to write my own blueprint and I'd like to know how could I tell to Jhipster some default values should be considered when loading a JDL.
I thought that if I just set the prompt attribute default would be the solution, but I did this and have no effect, the prompts are always shown. When there are more than one application declared in the JDL file it's worst because it's not possible to distinguish what is being answered to each application since this processes happen in parallel.
Regards,
application {
config {
baseName microserviceExample,
applicationType microservice,
prodDatabaseType postgresql
}
entities X
}
entity X {
name String required minlength(3)
}
Personally, I don't like depending on default values that could be changed by a new major version (e.g. default for service registry will change in JHipster 8 from Eureka to Consul).
Why is this a problem to explicit these values in your JDL? For me the JDL should be self contained as much as possible.
Alternatively, you could define a .yo-rc.json file in your project directory or in its parent directory if you want to apply to several apps below.
And finally, you could open a feature request on github for the dev team to comment.
When I am using same development keys and private rsa key in sample app provided by docusign then that is working. But when using same keys in my application is shows below error while creating envelope.
Sample app has docusign.esign.dll 4.1.1 and in my case its docusign.esign.dll 5.0.0.
Anything I am missing while calling CreateEnvelope or is there any configuration issue?
I can't see the code you used to obtain accessToken, but you should ensure that you provided the correct information and the same environment (account-d vs. account.docusign.com).
Also, you create a new Configuration() object called config, but then use _configuration in the code I can use. This is a bit odd. I wonder if you set the BaseUrl correctly for the _configuration object you did use.
Also, you need to pass the config object when to the API so that it is used.
i am new to Web-Development and so it is the first time, that I try to work with different environments.
So in my WebApp which is deployed on Azure I want to use a connectionString for my local database, when I am working locally in development environment, and when I deploy it, it should use a different database with another connectionString.
I have seen that there are two files in my Asp.Net Core project. "appsettings.json" and "appsettings.Development.json". If I understand correctly, app.dev.json should override the settings in app.json if I work in Development Environment. But it doesn`t. When I am debugging the app, to realy make sure that environment is set to development, it still uses appsettings.json.
You might be correct in term of Multiple Configuration Files. appsettings.json is a default configuration file that you can declare anything which includes both Development and Production. The merging pattern will be appsettings.{Environment}.json, then all matching keys will replace all keys in appsettings.json. Remembered the name Environment should be matched with ASPNETCORE_ENVIRONMENT to be used. In you case, app.dev.json so your environment should be dev (case-sensitive) instead of Development.
For example: We have a default `appsettings.json
{
"ConfigurationString": "mongodb://localhost:27017",
"MongoOptions": {
"AllowWireUp": true,
"AutoConnect": true
}
}
Then you want to work in Development, you create appsettings.Development.json with content
{
"ConfigurationString": "mongodb://192.168.1.1:27017",
"MongoOptions": {
"AllowWireUp": false
}
}
Later when you run with Development, you will get combined file
{
"ConfigurationString": "mongodb://192.168.1.1:27017",
"MongoOptions": {
"AllowWireUp": false
}
}
Important: You will see MongoOptions.AutoConnect is false in Development because .NET Core merges two files based on first level key instead of merging nested. That means MongoOptions in appsettings.Development.json will replace entire your appsettings.json
There is a way to do that. I guess you are using Azure app service?. if so follow thease steps
Create multiple app-settings files inside your project. (dev/ staging / uat / prod)
These file names shoud be appsettings.Development.json appsettings.uat.json and appsettings.Production.json
Each file should contain its own configurations.
Then Go to your App service in azure > configuration > Application settings , add required prifix of your appsettings json file in Value filed in ASPNETCORE_ENVIRONMENT
Restart app service. it should work now
To play with the demo-sessions app, I've got the oauth2 app mounted on /oauth2 as required.
In arangodb/Foxx doc, the oauth2 endpoints seems to be defined as strings (i.e https://github.com/arangodb-foxx/util-oauth2 )
But when I perform that with correct urls, and try to play with oauth, I've got an error :
...\oauth2\APP\manifest.json\": attribute child \"authEndpoint\" fails because [\"authEndpoint\" must be an object] (was \"[object Object]\").]","...
Oauth endpoints definitions are expected to be objects, not strings.
So what is the correct configuration for Foxx oauth2 ?
Thanks for help,
I can't reproduce your problem but the OAuth2 app has been updated for ArangoDB 2.7. You can still install odler versions of the OAuth2 app from the "install from GitHub" dialog, though.
I understand my mistake. In the code of the oauth2 2.0 release, the manifest just references the export.js file. In the previous release (1.2), a providers.js file was supplied and referenced in the manifest. Then in this previous release, it was possible to use different providers (what I want) as described in the 1.2 setup.js.
var providers = db._collection(providersName);
I just fetch the files providers.js, and setup.js from 1.2 github tag and configure them for my configuration, and that's ok.
-=UPDATE=-
The problem I was experiencing was a case where the certificate was valid, but the site was invalid for the certificate. Leaving the default settings (either providing a profile with the certificate default settings or using the standard :selenium driver in Capybara) worked for my case. I mistakingly thought I needed to modify my Firefox profile for the driver to work, this wasn't the case.
Removing the certificate settings from my custom profile fixed the issue. Thanks Jarib.
-=Original Question=-
I'm currently trying to setup my test browsers to ignore invalid SSL certificates when using Cucumber and Capybara. I have the following in my env.rb:
Capybara.register_driver :selenium_profile do |app|
profile = Selenium::WebDriver::Firefox::Profile.new
profile.secure_ssl = false
profile.assume_untrusted_certificate_issuer = false
Capybara::Selenium::Driver.new(app, :browser => :firefox, :profile => profile)
end
Capybara.configure do |config|
config.run_server = false
config.default_driver = :selenium_profile
config.default_wait_time = 15
end
The environment seems to be setup properly, and the testcase runs fine until I hit an invalid certificate.
Is there something I'm doing wrong in the code above? Is there another option (using script/code) to create a new profile that ignores certificates? I'm trying to do some black box testing on a qa site, so self signed certificates aren't really an option. Individual Firefox profiles aren't good since the code needs to be portable. Thoughts?
Environment:
OS X.7.3
Firefox 12.0
ruby-1.9.2
capybara (1.1.2 ruby, 0.4.1.2)
capybara-webkit (0.8.0)
cucumber (1.1.9)
selenium-webdriver (2.21.2)
Did you try without profile.assume_untrusted_certificate_issuer = false
and with profile.accept_untrusted_certs = True