I found an article on using external config files here. While I was able to extract my config settings, I was unable to put them in a central location.
When i tried to do something like this:
<connectionStrings configSource="C:/dev/Configs/ConnectionStrings.config" />
It causes a type initializer exception. If i put the file in a folder under the bin directory, it's ok. Problem is, I want to keep the config files central to all apps so i can reuse it in a lot of places.
Is it just not doable?
I ended up using Symbolic Links. I created a subfolder under each app that symlinked back to the master config folder. All apps share the same Connection Strings now.
Related
as you know We have a file for gitlab ci configuration named '.gitlab-ci.yml'
and this file shouldn't be edited by any developers so I decided to avoid developers to edit it.
the thing is gitlab said you can lock file to being edited but the prerequirement of this action is to have a premium account.
what can I do when I haven't premium account?
do you have any idea to lock a file to being edited?
Check if you have access to a Push Rule feature, which is a kind of pre-receive hook.
Or you can set a pre-receive hook if your GitLab server is on-premise.
In both cases, you can list the files being pushed in that hook, and fails if one of them is .gitlab-ci.yml.
As of today, the official way (~workaround~) for this seems to be creating a different repository for the .yml file with more restrict permissions and then referencing that .yml file from your project:
A .gitlab-ci.yml may contain rules to deploy an application to the production server. This deployment usually runs automatically after pushing a merge request. To prevent developers from changing the .gitlab-ci.yml, you can define it in a different repository. The configuration can reference a file in another project with a completely different set of permissions (similar to separating a project for deployments). In this scenario, the .gitlab-ci.yml is publicly accessible, but can only be edited by users with appropriate permissions in the other project.
https://docs.gitlab.com/ee/ci/environments/deployment_safety.html#protect-gitlab-ciyml-from-change
Also, there is a discussion on this matter here:
https://gitlab.com/gitlab-org/gitlab/-/issues/15632
In our Apache Camel project, we are consuming a rest service which requires a .jks file.
Currently we are storing .jks file in a physical location and referring to that in Camel project. But it can't be used always, as we may be having access to the Fuse Management Console only and not to the physical location accessible from management console.
Another option is to store key file within bundle, which is can't be employed because, certificate may change based on the environment.
In this scenario, what can be a better solution to store key file?
Note
One option about which I thought was, storing .jks file within fabric profile. But could n't find any way to do that. Is it possible to store a file in Fabric profile?
What about storing the .jks in a java package and reading it as a resource?
You bundle imports org.niyasc.jks and loads the file from there. The bundle need not to change between environments.
Then you write 2 bundles to provide the same package org.niyasc.jks, one with production file and one with test file.
Production env:
RestConsumerBundle + ProductionJksProviderBundle
Test env:
RestConsumerBundle + TestJksProviderBundle
Mind that deploying both of them may be possible and RestConsumerBundle will be bound to the first deployed bundle. You can eventually play with OSGi directives to give priority to one of them.
EDIT:
A more elegant solution would be creating an OSGi service which exposes the .jks as an InputStream or byte[]. You can even play with JNDI if you feel to.
From Blueprint declare the dependency as mandatory, so your bundle will not start if the service is not available.
<!-- RestConsumerBundle -->
<reference id="jksProvider"
interface="org.niyasc.jks.Provider"
availability="mandatory"/>
Storing the JKS files in the Fuse profile could be a good idea.
If you have a broker profile created, such as "mq-broker-Group.BrokerName", take a look at it via the Fuse Web Console.
You can then access the jks file as a resource in the property file, as in "truststore.file=profile:truststore.jks"
And also check the "Customizing the SSL keystore.jks and truststore.jks file" section of this chapter:
https://access.redhat.com/documentation/en-us/red_hat_jboss_fuse/6.3/html/fabric_guide/mq#MQ-BrokerConfig
It has some good pointers.
Regarding how to add files to a Fabric profile, you can store any resources under src/main/fabric8 and use the fabric8 Maven plugin. For more, see:
https://fabric8.io/gitbook/mavenPlugin.html
-Codrin
I have written an application in CakePHP 3.x and there is a form to upload files.
At present, files are being uploaded to WWW_ROOT.'files' which is /app/webroot/files/ path.
To store files separately from core application, I created a subdomain cdn.example.com whose path is like /home/user/example.com/cdn.example.com/.
since, uploading files requires absolute path, how can I get absolute path of the subdomain cdn.example.com same as $_SERVER['DOCUMENT_ROOT']; from example.com?
First check if your server allow to write files from main domain to subdomain.
You can't get the absolute path of a different domain of the one you deployed your application, you should store the path in a variable or in constant.
If you really need to store files in another domain/subdomain and any path is blocked you should consider to reupload the files via FTP script.
I'm using "github.com/dgrijalva/jwt-go" to create JSON web tokens.
When I hosted my server locally, I could use my private key as usual. But in GAE it won't work because I don't have access to the file system.
How would you guys do it? Store the key in datastore or any other ideas?
Thanks
Edit:
My app.yaml looks like this (below api_version and stuff):
handlers:
- url: /.*
script: _go_app
On AppEngine you don't have access to the file system of the host operating system, but you can access files of your web application (you have read-only permission, you can't change them and you can't create new files in the app's folder).
So the question is: do you want to change this private key from your application without redeploying your app? Or it is perfectly fine if it is deployed "statically" with your app's code?
If you don't need to change it (or only when you redeploy your app), easiest is to store it as a "static" file as part of your webapp. You may refer to files of your app using relative paths, where the current or working directory is your app's root. E.g. if your app contains a key folder in its root (where app.yaml resides), and there is a my_key.txt file inside the key folder, you can refer to it with the path: key/my_key.txt.
Actually it is quite common to "ship" static files with your app's code: just think of HTML templates which are read and processed by the Go code (e.g. package html/template) to produce HTML result; the content of the HTML template files are not served directly to clients.
If you need to change it from time to time without having to redeploy your app, then store it in the Datastore which your app can read and modify.
Note:
One important note: not every file is readable by code, this depends on the app configuration. Quoting from Configuring with app.yaml / Static file handlers:
Static files are files to be served directly to the user for a given URL, such as images, CSS stylesheets, or JavaScript source files. Static file handlers describe which files in the application directory are static files, and which URLs serve them.
For efficiency, App Engine stores and serves static files separately from application files. Static files are not available in the application's file system. If you have data files that need to be read by the application code, the data files must be application files, and must not be matched by a static file pattern.
Static file handlers can be defined in two ways: as a directory structure of static files that maps to a URL path, or as a pattern that maps URLs to specific files.
Read the link how to properly configure application and static files / directories.
The solution was to leave app.yaml as it were. Put app.yaml at root lvl in project. Then change all imports from starting at GOPATH to start at project root instead. The problem that made me choose to put app.yaml and main go file in a different folder under project root was because of double imports. Read this for a better understanding: Google Go AppEngine imports and conflicts when serving / testing
The solution made my project find the files I wanted.
I have a rest app with resteasy, which creates files and stores them and return the path, so I can see the name in the screen. The problem: When I want to download the file, I create the url with "app url" + "file path" but that doesn't work. The message is:
Could not find resource for relative : /publications_report_486.doc of full path:
http://127.0.0.1:8080/SIISA-Rest-0.6/publications_report_486.doc
In this example, I store the file in the app's root, so I just have to add the filename to the url.
I think resteasy is trying to find that url within their resources(services) and it doesn't find the path, so it doesn't access to the file, it just search the services.
How could I fix this?
I'm not sure how to return the file from within Resteasy - I've been looking for that myself which is how I stumbled across this, but you could probably deal with this particular problem by tweaking the your web.xml so that it doesn't include the location where you store your files in the servlet-mapping to Resteasy. You may want to have a look at the approach in this answer.