How to set proxy in keystone js - amazon-s3

I am new in Keystone JS and I observed there is no much support available on google for it.
I am uploading files to S3 on AWS, but I am facing timeout issue, I figured out that, I need to set proxy for it.
But I don't know how to set proxy in keystone, I searched on its site but found nothing.
Note:: I am using keystone.storage and keystone-storage-adapter-s3

The package keystone-storage-adapter-s3 that you are using is using knox, and knox's proxy support proxy was added in pull 137.
After make sure you have updated knox, you can add your proxy options to
var storage = new keystone.Storage({
adapter: require('keystone-storage-adapter-s3'),
s3: {
key: 's3-key', // required; defaults to process.env.S3_KEY
secret: 'secret', // required; defaults to process.env.S3_SECRET
bucket: 'mybucket', // required; defaults to process.env.S3_BUCKET
proxy: '<your proxy>',
...
More information:
Setting proxy server for connections in Knox
https://www.npmjs.com/package/keystone-storage-adapter-s3
https://github.com/keystonejs/keystone-storage-adapter-s3/blob/master/index.js
Note: I have not try this but I just provide the information based on the source code trace, good luck.

Related

How to set up the remote host and Bearer configuration within Angular Template for .Net 6?

I can't find a way to figure out where is the host name configuration provided for the SPA application to connect to.
The command passed into the application from ASP.NET Core server while running the SPA is
ng serve --port 44472 --ssl --ssl-cert %APPDATA%\ASP.NET\https\%npm_package_name%.pem --ssl-key %APPDATA%\ASP.NET\https\%npm_package_name%.key
And I could not find any of the above strings localhost:7219, or 5219, or 7219 in the ClientApp / ClientApp/src folder (7219 and 5219 are the server ports and 44472 is the client npm port).
Do the server URLs passed from launchSettings.json asp project directly?
If so, if there a way to configure the server URLs directly from ClientApp if the client application is run from a different host, other than localhost (any where the settings (are | should be) stored)?
I can see the #Injected service everywhere but where does it store the settings is unclear (for how to configure this injected BASE_URL?):
constructor(http: HttpClient, #Inject('BASE_URL') baseUrl: string) {
http.get<WeatherForecast[]>(baseUrl + 'weatherforecast').subscribe((result : any) => {
this.forecasts = result;
}, (error : any) => console.error(error));
}
The derived question is: should by default the client Bearer authorization also work for a remote host?
The remote host for example is github pages. How to properly set the remote host configuration within client application for a particular webpack deployment with angular-cli-ghpages if the CORS hosts are configured within Program.cs? Should the client configuration for a remote host (apart from localhost) or server CORS configuration, include additional "Bearer-Cors" configuration (as for the certificate npm start script mentioned in the question above – should it be just skipped without any parameters passed in it)?
Are there any comprehensive guidelines on this subject?
Half of the answer to this question is that the template uses proxy config, which is described here https://angular.io/guide/build#proxying-to-a-backend-server and stores the configuration in proxy.conf.js within ClientApp folder. I will try to extend my answer with any found information in the future.
Update: The second part of the answer is to add the Cookie.SameSite = SameSiteMode.None; cookie authorization configuration in Startup.cs / Program.cs. Take a look at the solution: https://stackoverflow.com/a/75239406/6897369

getting Missing credentials in config, if using AWS_CONFIG_FILE, set AWS_SDK_LOAD_CONFIG=1 despite having credentials in config file

I have a typescript/node-based application where the following line of code is throwing an error:
const res = await s3.getObject(obj).promise();
The error I'm getting in terminal output is:
❌ Missing credentials in config, if using AWS_CONFIG_FILE, set AWS_SDK_LOAD_CONFIG=1
CredentialsError: Missing credentials in config, if using AWS_CONFIG_FILE, set AWS_SDK_LOAD_CONFIG=1
However, I do actually have a credentials file in my .aws directory with values for aws_access_key_id and aws_secret_access_key. I have also exported the values for these with the variables AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY. I have also tried this with and without running export AWS_SDK_LOAD_CONFIG=1 but to no avail (same error message). Would anyone be able to provide any possible causes/suggestions for further troubleshooting?
Install npm i dotenv
Add a .env file with your AWS_ACCESS_KEY_ID etc credentials in.
Then in your index.js or equivalent file add require("dotenv").config();
Then update the config of your AWS instance:
region: "eu-west-2",
maxRetries: 3,
httpOptions: { timeout: 30000, connectTimeout: 5000 },
accessKeyId: process.env.AWS_ACCESS_KEY_ID,
secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
});
Try not setting AWS_SDK_LOAD_CONFIG to anything (unset it). Unset all other AWS variables. In Mac/linux, you can do export | grep AWS_ to find others you might have set.
Next, do you have AWS connectivity from the command line? Install the AWS CLI v2 if you don't have it yet, and run aws sts get-caller-identity from a terminal window. Don't bother trying to run node until you get this working. You can also try aws configure list.
Read through all the sections of Configuring the AWS CLI, paying particular attention to how to use the credentials and config files at $HOME/.aws/credentials and $HOME/.aws/config. Are you using the default profile or a named profile?
I prefer to use named profiles, but I use more than one so that may not be needed for you. I have always found success using the AWS_PROFILE environment variable:
export AWS_PROFILE=your_profile_name # macOS/linux
setx AWS_PROFILE your_profile_name # Windows
$Env:AWS_PROFILE="your_profile_name" # PowerShell
This works for me both with an Okta/gimme-aws-creds scenario, as well as an Amazon SSO scenario. With the Okta scenario, just the AWS secret keys go into $HOME/.aws/credentials, and further configuration such as default region or output format go in $HOME/.aws/config (this separation is so that tools can completely rewrite the credentials file without touching the config). With the Amazon SSO scenario, all the settings go in the config.

Using Spring Cloud Vault and ConfigData API with multiple profile files

I have 5 profiles for my Spring Boot application
application.yml
application-prod.yml
application-stg.yml
application-dev.yml
application-local.yml
One default config and 4 for different environments.
application.yml looks like this
spring:
cloud:
vault:
enabled: ${VAULT_ENABLED:false}
host: ${VAULT_HOST}
port: ${VAULT_PORT}
authentication: aws_iam
aws-iam:
role: ${VAULT_POLICY}
server-name: ${VAULT_HOST}
kv:
backend: kv
enabled: true
Some of the properties are provided by the host in the environment variables.
To support local development I am overriding authentication in local profile like this
spring:
cloud:
vault:
enabled: true
authentication: token
token: ${VAULT_TOKEN}
Now the question is how to import config correctly?
If I will do spring.config.import: "vault:" in application.yml it will fail while running with local profile. As ConfigData API will try to resolve vault properties immediately after default profile is processed (but auth info not yet loaded). But as local profile is supposed to use different auth method, it cannot access Vault and fails.
Another question is how to disable Vault in some cases? I could do spring.cloud.vault.enabled=false, but this again would cause failure as ConfigData cannot resolve vault:.
Yes I could use legacy bootstrap mode which would work fine for my scenario, but in the longer run wouldn't be ideal...
Only thing that comes on my mind is to create additional profile, eg vault which would be loaded as a last one. With enabling / disabling this profile I could control if config from Vault is imported or not...
Any other ideas?
We have the same problem, but we have found a workaround overriding the default import order of Spring Boot by importing also the profile-specific configuration files explicitly using spring.config.import in application.yml like this:
spring:
profiles:
active: ${STAGE:local}
config:
import:
- optional:classpath:application-${STAGE:local}.yml
- vault://secret/our-secret
Note that the STAGE environment variable corresponds to the profile used per stage. We made the import of the profile-specific configuration file optional, as we don't have a dedicated file for every stage.
By providing the import for the profile-specific configuration files explicitly before the vault config, we can override the default vault settings before the vault is accessed.
Still, this approach feels a bit awkward, but it's the only way so far we found to work around the issue, so better solutions would be appreciated.

Spring Cloud Config Basic Security throwing 401 error

I have following configuration on server side:
server:
port: 8888
spring:
profiles:
active: native
cloud:
config:
server:
native:
search-locations: "classpath:/config"
security:
user:
name: test
password: test
And following configuration on client side:
spring:
cloud:
config:
fail-fast: true
profile: "${spring.profiles.active}"
uri: "${SPRING_CLOUD_CONFIG_URI:http://localhost:8888/}"
username: test
password: test
I can successfully access properties from browser using user/pwd as test/test, but when my client tries to fetch it failed with 401 error:
INFO 7620 --- [5cee934b64bfd92] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at : http://localhost:8888
WARN 7620 --- [5cee934b64bfd92] c.c.c.ConfigServicePropertySourceLocator : Could not locate PropertySource: 401 null
I tried setting the log level for spring cloud to DEBUG but nothing additional got logged, so I have no clue why I'm getting a 401 from client while I can access properties successfully via browser using the same credentials.
I've also tried removing the security from server and client and it worked perfectly, which means rest of the configurations are quite ok. But then the question is, what am I overlooking when I apply basic security and why it is not working and throwing a 401 instead?
Try checking these configurations:
spring.cloud.config.username
spring.cloud.config.password
Both properties should be defined at bootstrap.properties (not application.properties)
Please check if the way you are specifying profile name is correct and if it is getting resolved properly in Java code. You can implement CommandLineRunner and print active profiles from Environment variable.
If you specified property spring.profiles.active as native in pom.xml, you can resolve it in application/yaml file as #spring.profiles.active#
If you specified property file as VM argument, then it should work with current implementation.
If you did not specify spring.profiles.active in pom or VM argument, it will resolve to default profile, not native profile. Profile in config client and config server should be same.
Yes we have to use bootstrap properties because When the Spring Cloud application starts, it creates a bootstrap context. The bootstrap context is searching for a bootstrap.properties or a bootstrap.yaml file, whereas the application context is searching for an application.properties or an application.yaml file. The bootstrap context is the parent context for the main application

Node.js + SSL support

Recent commits reference TLS progress. Any idea when it will be ready?
If not, what are the options for using SSL with a node app at the present time? Reverse proxy nginx? Is there a good tutorial available for using SSL with node?
Most professional apps need to support SSL these days and it would be great to be able to use node for these now.
Node.js 0.3.4 has been released.
Primordal mingw build (Bert Belder)
HTTPS server
Built in debugger 'node debug script.js'
realpath files during module load (Mihai Călin Bazon)
Rename net.Stream to net.Socket
Fix process.platform
Example
var https = require('https');
var fs = require('fs');
var options = {
key: fs.readFileSync('test/fixtures/keys/agent2-key.pem'),
cert: fs.readFileSync('test/fixtures/keys/agent2-cert.pem')
};
https.createServer(options, function (req, res) {
res.writeHead(200);
res.end("hello world\n");
}).listen(8000);
Node 3.x is not supposed to be used in production, it's unstable, bleeding edge development. 2.6 still has the old SSL implementation, which works.
If you want to know when all the stuff gets finished, your best bet is to either ask on the Google Group, or Ryan on Twitter.
Just for reference ... here's a JavaScript implementation of SSL/TLS:
https://github.com/digitalbazaar/forge
At the moment, it is only a client-side implementation. It would need to be expanded to cover server-side. For someone with a little knowledge about how TLS works, however, it shouldn't be too difficult to add to the existing framework.
From my experience node 0.2 SSL support is very flacky and unreliable.
We use nginx as a proxy.