I have a Spring Cloud Config app with the Spring Cloud Security dependencies. I'm trying to hit the /encrypt endpoint to encrypt a password.
According to the docs at http://cloud.spring.io/spring-cloud-config/spring-cloud-config.html#_key_management I believe I need to set a symmetric key using "encrypt.key". But I can't figure out where to put this; all combinations I've tried result in {"description":"No key was installed for encryption service","status":"NO_KEY"} when I attempt to POST to /encrypt.
If I POST a key to /key, the /encrypt works perfectly, so I'm pretty sure that everything else is setup correctly. It also works fine using the environment variable ENCRYPT_KEY, or by using a system property encrypt.key. I just can't figure out where to place the encrypt.key within a configuration file. Is there a sample on this?
Thanks #pVilaca, this is indeed what the documentation says, but setting the key in application.properties or application.yml won't work.
Through experimentation I've found that the only place you can set the encrypt.key property is an ENCRYPT_KEY environment variable, a system property, bootstrap.properties, bootstrap.yml, or calling the /key endpoint.
Not sure why application.properties or application.yml don't work in this case. Setting this key must have more of an impact on the startup process than it would appear.
Setting Spring Cloud Version to 'Brixton.SR5' worked for me. For some reason, setting 'encrypt.key' in either application.properties/yml or bootstrap.properties/yml in later Spring Cloud Version does not work anymore.
check properties tag of pom.xml file. If you are using version 2 or 3 of Dalston, change it to:
<spring-cloud.version>Dalston.SR1</spring-cloud.version>
and it should be working fine. In my case i was using version 3 and changing it to version 1 resolved the issue for me.
Reference:
https://github.com/spring-cloud/spring-cloud-config/issues/767
If you're using spring cloud with spring boot, that is the method that is described on the documentation that you mentioned, you've two 'main' properties files.
bootstrap.[properties,yml]
To modify the startup behaviour you can change the location of the config server using bootstrap.properties (like application.properties but for the bootstrap phase of an application context)
application.[properties,yml]
where the "application" is injected as the "spring.config.name" in the SpringApplication (i.e. what is normally "application" in a regular Spring Boot app)
source: Spring Cloud Config Documentation
So, it should be enough to set the encrypt.keyin your application.[properties,yml] file (or the alternative name if specified)
I would like to implement a standalone oai-pmh version 2 data provider server using xoai 4.1.x without DSpace.
Can anyone direct me to any documentation for doing this or to a reference implementation?
Thanks
David
Its posible, but you will need a repository to manage the contents that oai serve.
You should check https://github.com/lyncode/xoai/wiki for help and https://github.com/lyncode/xoai to get the code.
I'm using the Jira (version 5) Rest API to Delete a version and like the documentation tell me, I pass the moveFixIssuesTo and moveAffectedIssuesTo to transfer issue from the deleted version to a other version. This just doesn't work. The issues that has AffectedVersion / FixVersion set to the deleted version have no version after the delete.
/rest/api/2/version/{id}?moveFixIssuesTo&moveAffectedIssuesTo
Here an example of the call :
http:// /rest/api/2/version/16238?16237&16237
My {id} is an existing versionId I want to delete.
moveFixIssuesTo and moveAffectedIssuesTo are versionId of the version I want the issues to be transfer.
If I do the same kind of action from the Web UI of Jira ( Deleting a version and setting in the form the version to transfer the AffectedVersion and FixVersion, It work correctly and I see the new version in the field of the issues.
Any idea why this does not work as expected ?
I think if you changed implementation of service operation - you must use another url for this operaton. For this thing you can change value of attribute version in rest tag in the file atlassian-plugin.xml:
<rest name="My Rest Resource" key="custom-rest-resource" path="/my-custom-resource" version="1.0"/>
I have 1.3.2 installed. My investigations found this in scripts/DbmDiff.groovy:
// TODO this will fail with JNDI or encryption codec
buildOtherDatabase = { String otherEnv ->
Searching the web lead me to this:
https://github.com/grails-plugins/grails-database-migration/commit/ac38a7310fe48ba7b5c4dda4d6e30dd8040dbeb6
which is code for DbmDiff.groovy, but in spite of the same TODO comment, appears to handle jndi.
Does this mean that a 1.3.3 is coming soon with jndi support? If so, then I can work around for a while using a temporary env using urls etc.
Regards, John
I'm not sure when 1.3.3 will be released since this is the only fix so far. It shouldn't be too soon though. Until then you can copy the current script to your application's scripts folder. Then you run grails dbm-diff Grails will ask you which of the two scripts to run.
As
Holders.grailsApplication.mainContext.servletContext.getRealPath("/")
is not available anymore in application.groovy in recent Grails versions, I wonder how to get dynamic (webapp-name-dependent) datasources working again?
see
https://github.com/grails/grails-core/issues/10131
the same applies for Holders with the extend that in runtime.groovy, Holders.grailsApplication is not available so I cannot find a way to set properties with values related to the context path.
Now I try to find a way to get our deployment scenario (same webapp deployed on same server, but each has another datasource)