Rather than storing a credentials file on the server, we opted to use env vars to store the required info:
GOOGLE_CLIENT_ID
GOOGLE_CLIENT_EMAIL
GOOGLE_ACCOUNT_TYPE
GOOGLE_PRIVATE_KEY
And we're obtaining authorization for a CalendarService as follows:
scopes = ["https://www.googleapis.com/auth/calendar"]
auth = ::Google::Auth.new_application_credentials(scopes)
service = ::Google::Apis::CalendarV3::CalendarService.new
service.authorization = auth
service.authorization.fetch_access_token!
Every part of the process works locally - authorizing, fetching an access token, interacting with API, etc. When we deploy to our staging environment on Heroku, we can't get past the following error:
Unable to read the credential file specified by GOOGLE_APPLICATION_CREDENTIALS: Neither PUB key nor PRIV key: nested asn1 error
I had seen this error in testing so I know it can be related either to a missing credentials file (like the error indicates) OR to an invalid id, private key, or email combination (because I was accidentally replacing the private key with an invalid value). In that situation, the error message was identical.
We have verified that all vars match the credentials used locally - what am I missing?
Make sure you are setting properly the GOOGLE_PRIVATE_KEY variable.
On Heroku to set a multi-line config variable you need to run:
heroku config:add GOOGLE_PRIVATE_KEY="$(cat private_key_file)"
An alternative to storing the key in a new file and using cat would be to use printf instead.
heroku config:add GOOGLE_PRIVATE_KEY="$(printf "-----BEGIN PRIVATE KEY.....")"
Related
I wanted to know if it is possible to connect to an external database or service from the CustomGatewayJWTGenerator https://github.com/wso2/samples-apim/blob/master/CustomGatewayJWTGenerator/src/main/java/org/wso2/carbon/test/CustomGatewayJWTGenerator.java
Can we propagate ENV variables to the class, for example with the url of the service to invoke? How to know the service to invoke (depending if sandbox or production)?
Additionaly, is there anyway to access the OAuth scope in this class? Is it possible with JWTValidationInfo scopes?
Yes, you can pass an env value or a system property to this class.
Environment variable: Set the env value to the shell.
System.getenv("ENDPOINT")
System Property: When starting the server you can set the system property as ./api-manager.sh -DENDPOINT="https://localhost:9090"
System.getProperty("ENDPOINT")
You can get the key type which comes as production or sandbox as follows.
jwtInfoDto.getKeyType()
You can get the scopes from here.
jwtInfoDto. getJwtValidationInfo().getScopes();
I've got a Next.js application that uses AWS Cognito userpools for authentication. I have a custom UI and am using the aws-amplify package directly invoking signIn/signOut/etc... in my code. (I previously used the AWS Hosted UI and had the same problem set out below - I hoped switching and digging into the actual APIs who reveal my problem but it hasn't)
Everything in development (running on localhost) is working correctly - I'm able to login and get access to my current session both in a page's render function using
import { Auth } from 'aws-amplify';
...
export default const MyPage = (props) => {
useEffect(async () => {
const session = await Auth.currentSession();
...
}
...
}
and during SSR
import { withSSRContext } from 'aws-amplify';
...
export async function getServerSideProps(context) {
...
const SSR = withSSRContext(context);
const session = await SSR.Auth.currentSession();
...
}
However, when I deploy to AWS Amplify where I run my staging environment, the call to get the current session during SSR fails. This results in the page rendering as if the user is not logged in then switching when the client is able to determine that the user is in fact logged in.
Current Hypothesis - missing cookies(??):
I've checked that during the login process that the AWS cookies are being set correctly in the browser. I've also checked and devtools tells me the cookies are correctly being sent to the server with the request.
However, if I log out context.req.headers inside getServerSideProps in my staging environment, the cookie header is missing (whereas in my dev environment it appears correctly). If this is true, this would explain what I'm seeing as getServerSideProps isn't seeing my auth tokens, etc... but I can't see why the cookie headers would be stripped?
Has anyone seen anything like this before? Is this even possible? If so, why would this happen? I assume I'm missing something, e.g. config related, but I feel like I've followed the docs pretty closely - my current conf looks like this
Amplify.configure({
Auth: {...}
ssr: true
});
Next.js version is 11.1.2 (latest)
Any help very much appreciated!
You have to use Next#11.0.0 to use getServerSideProps, withSSRContext and Auth module in production.
I had same issue.
My solution was that disconnect a branch has an authentication problem once and reconnect the branch.
What are your build settings? I guess you are using next build && next export in which case this getServerSideProps shall not work. See https://nextjs.org/docs/advanced-features/static-html-export#unsupported-features
To use SSR with AWS amplify see https://docs.aws.amazon.com/amplify/latest/userguide/server-side-rendering-amplify.html#redeploy-ssg-to-ssr or consider deploying on a node server that is actually a server that you can start with next start like AWS EC2 or deploy on Vercel.
Otherwise if you use next export have to make do with client side data fetch only with client side updates only and cannot use dynamic server side features of nextjs.
One reason for context.req.headers not having any cookie in it is because CloudFront distribution is not forwarding any cookies.
This “CloudFront Behaviour” can be changed in two ways:
Forward all cookies, OR
Forward specified cookies (i.e. array of cookie names)
To change the behaviour, navigate to CloudFront on AWS console > Distributions > your_distribution > Behaviors Tab.
Then Edit existing or Create new behaviour > Change cookies settings (for example set it to "All")
I am creating a postman collection for one of API integration with our Service. Here we are using OAuth1.0 for authentication. I want to set the oauth init response oauth_token, oauth_token_secret into postman environment variables so that I can access them in further requests.
The response is in below format not a JSON.
oauth_token=oauth_token_value&oauth_token_secret=oauth_token_secret_value&oauth_callback_confirmed=true
I tried below script:
var output = require('querystring').parse(Response.text);
postman.setGlobalVariable("oauth_token", output.oauth_token);
postman.setGlobalVariable("oauth_token_secret", output.oauth_token_secret);
Can some one help me to set tokens into postman environment variables please.
Note: I am using chrome plugin Version 5.5.4, not native app.
In the chrome extension you need to use postman.setEnvironmentVariable():
postman.setEnvironmentVariable("oauth_token", output.oauth_token);
postman.setEnvironmentVariable("oauth_token_secret", output.oauth_token_secret);
For that you need to have an environment created and selected (no need to add any variable manually). How to do that is described here: https://learning.postman.com/docs/sending-requests/managing-environments/#creating-environments
I'm implementing a REST Api which need download files from Amazon S3.
When I call the api, it gives me the exception:
com.amazonaws.AmazonClientException: Cannot load the credentials from the credential profiles file. Please make sure that your credentials file is at the correct location (~/.aws/credentials), and is in valid format.
Then I run the same method API called, it succeeded. I'm using tomcat 9.0.2, my guess is the default credential directory ~/.aws/credential is different for tomcat application.
So I checked $CATALINA_HOME, which is /opt/apache-tomcat-9.0.2 and I copied the credentials there, still not working.
First time asking questions here, I hope that I expressed my issue clearly. Thanks for any help from anybody.
The home directory ~ depends on the user running the Tomcat server, so if Tomcat is running as the root user, for example, you'd need to place the credentials in /root/.aws/credentials.
Depending on the Tomcat version, you can usually find the default user in /etc/default/tomcat7. It would appear as something like:
TOMCAT7_USER=tomcat7
In that case, the home directory would be /home/tomcat7, and thus the credentials would go in /home/tomcat7/.aws/credentials.
I've setup a private composer repository via gem-fury, but when I'm trying to download one of the packages (using composer-require) I receive the following error:
[Composer\Downloader\TransportException]
The 'https://s3.amazonaws.com:443/gemfury/gems/[SOME_STRING]/[VENDOR][PACKAGE]_[VERSION]_zip?Signature=SIGNATURE&Expires=1481739039&AWSAccessKeyId=[AWS_ACCESS_KEY]' URL could not be accessed: HTTP/1.1 400 Bad Request
P.S.
I know that the authentication worked because composer does receive the package.json file (the latest version is recognized)
Any help would be appretiated
Short answer: You may see this issue if you are using auth.json to store your Gemfury token. At this time, the only way to work around this issue is to embed the token directly into your repository URL in composer.json.
Long answer: The reason it doesn't work is due to a bug in Composer CLI. In that particular use-case, when Composer acts on Gemfury's redirect from your private php.fury.io repo to a secure S3 download, it includes the Authorization header with your Gemfury token. This header conflicts with S3's authentication model, and results in a 400 Bad Request response.
Resending Authorization header on a redirect from one host to another is a fairly significant security concern, and I recommend you reset your Gemfury token and stop using auth.json authentication method until this issue is resolved.