AWS ElasticBeanstalk: JWT token not being validated after configuration change - django

Using AWS console, I changed configuration setting of api key for a third-party service. Then all of a sudden, the following error is popping up on my live server.
{"detail":"Authentication credentials were not provided."}
It seems JWT token is not being validated(or passed). After hours of googling, I found that the error is caused by EB apache setting
Apparently, by setting,
container_commands:
01_wsgipass:
command: 'echo "WSGIPassAuthorization On" >> ../wsgi.conf'
in *.config, the problem should go away. I did exactly the same, with the code in wgsi_enabled_pass.config created within .ebextensions but it is still not working.
Please help the newbie pros! Thanks in advance!

Add this to a .ebextensions/customize_httpd.config file:
files:
"/etc/httpd/conf.d/wsgi_custom.conf":
mode: "000644"
owner: root
group: root
content: |
WSGIPassAuthorization On
This is more reliable then trying to concat to a conf file that may or may not exist.

#nbeuchat
If I rememeber correctly, try restarting the app from EBS console, or re-deploy the codes AFTER setting the container_commands in *.config as in the question. If this does not fix the problem, let me know. I'll look into what I did in the past to fix the bug.

Related

Spring Boot on AWS Elastic Beanstalk and logging to a file

I have been looking to find an easy way to view debug statements on Beanstalk as I develop. I thought I could simply log to a file on Beanstalk.
In my application.properties file I set
logging.file.path=/var/log
And that did not produce any results even on my local machine. I am not sure if it's a permission issue or what, but locally I set the path to my home directory and then I saw the file, spring.log, appear.
With Beanstalk I tried /var/log, var/log/tomcat, /home/webapp/, ./, ~, and various other values. Nothing worked.
I even tried what was suggested here with no luck: https://medium.com/vividcode/logging-practice-for-elastic-beanstalk-java-apps-308ed7c4d63f
If logging to file is not a good idea, what are the alternatives? I have Googled a lot about this issue and all answers are not very clear.
Yes, this is permission issues. Your app runs under webapp user, while /var/log is own by root. Thus you can't write to it.
The proper way of adding your log files to be recognized by EB is through config files.
Specifically, assuming Amazon Linux 2, you can create .ebextensions/mylogfiles.config with the content of:
files:
"/opt/elasticbeanstalk/config/private/logtasks/bundle/myapplogs.conf":
mode: "000644"
owner: root
group: root
content: |
/var/app/current/log/*.log
Obviously, /var/app/current/log/*.log would point to location where your app stores its log files. /var/app/current is the home folder of your app.

AWS eb init not a valid key=value pair (missing equal-sign)

I was trying to set up a basic rails app and deploy it to Elastic Beanstalk. I ran eb init, picked my region and it asked for (aws-access-id): and (aws-secret-key):. For what ever reason it wasn't accepting my credentials and without realizing it at one point I had accidentally ran a command eb --version in the (aws-access-id): line. Now I can't get past choosing my region. I get
ERROR: ServiceError - '--version/20190924/us-west-2/elasticbeanstalk/aws4_request' not a valid key=value pair (missing equal-sign) in Authorization header: 'AWS4-HMAC-SHA256 Credential=eb --version/20190924/us-west-2/elasticbeanstalk/aws4_request, SignedHeaders=content-type;host;x-amz-content-sha256;x-amz-date, Signature=afc27125738fef1062fc8565e130ced6e0f7b2c343c2e28456d7693c8f396c92'.
I have been looking for a solution for countless hours now and can't find anything. I tried deleting .elasticbeanstalk file(some had mentioned), uninstalling it altogether, aws configure and put in the proper credentials, followed other stackoverflow questions. Nothing seems to work and the error will not go away. Tried looking up how to reset the headers. Not sure why this was saved in the first place. I feel it should have just given me wrong credentials if anything.
WS eb init missing equal-sign error
I am on a mac.
Okay, finally figured it out thanks to the link in my question to another similar stack overflow question. What I did was cd to my root directory where I finally did $ ls -a to see hidden files and saw .aws. I $ cd .aws and then ran $ open config. It open this
aws_access_key_id = eb --version
aws_secret_access_key = ENTER_SECRET_HERE
[default]
output = json
region = 3
Changed the key_id and access_key and it worked! Hope it helps out someone else before going insane.
in order to find the problem I used the cmd
eb init --verbose --debug
which included the output "...not a valid key=value pair (missing equal-sign) in Authorization header..."
I then googled that and was lead to your post. thanks!

How to access UI in Airflow 1.10?

To start with I am trying to upgrade from 1.9 version to 1.10 so my setup contains two vms running different versions of airflow with different port forwarding.
I can access UI from vm running with 1.9 but not able to access UI from 1.10.
To debug I want to confirm if airflow webserver is running. if I execute
sudo systemctl start airflow-webserver
it throws no error but when
I am looking at netstat I am not seeing any process listening to port 8080(default).
Also I have not created any user as I do not need rbac authentication ? Can that be a problem?
As requested by #kaxil. Below is the output of ps aux | grep airflow
Can someone provide some suggestions on how to fix this problem? Also if you need any further resource can provide it. I am not sure what is relevant here.
Output of journalctl -u airflow-webserver.service -b
The Error message shows that there is an issue with airflow.cfg file i.e. there might be a character in your airflow.cfg that is causing the issue. Recheck your config file, if you don't find an issue, post your config file in your question and we will try to figure it out.

Authorization Credentials Stripped --- django, elastic beanstalk, oauth

I implemented a REST api in django with django-rest-framework and used oauth2 for authentication.
I tested with:
curl -X POST -d "client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET&grant_type=password&username=YOUR_USERNAME&password=YOUR_PASSWORD" http://localhost:8000/oauth2/access_token/
and
curl -H "Authorization: Bearer <your-access-token>" http://localhost:8000/api/
on localhost with successful results consistent with the documentation.
When pushing this up to an existing AWS elastic beanstalk instance, I received:
{ "detail" : "Authentication credentials were not provided." }
I like the idea of just having some extra configuration on the standard place. In your .ebextensions directory create a wsgi_custom.config file with:
files:
"/etc/httpd/conf.d/wsgihacks.conf":
mode: "000644"
owner: root
group: root
content: |
WSGIPassAuthorization On
As posted here: https://forums.aws.amazon.com/message.jspa?messageID=376244
I thought the problem was with my configuration in django or some other error type instead of focusing on the differences between localhost and EB. The issue is with EB's Apache settings.
WSGIPassAuthorization is natively set to OFF, so it must be turned ON. This can be done in your *.config file in your .ebextensions folder with the following command added:
container_commands:
01_wsgipass:
command: 'echo "WSGIPassAuthorization On" >> ../wsgi.conf'
Please let me know if I missed something or if there is a better way I should be looking at the problem. I could not find anything specifically about this anywhere on the web and thought this might save somebody hours of troubleshooting then feeling foolish.
I use a slightly different approach now. sahutchi's solution worked as long as env variables were not changed as Tom dickin pointed out. I dug a bit deeper inside EB and found out where the wsgi.conf template is located and added the "WSGIPassAuthorization On" option there.
commands:
WSGIPassAuthorization:
command: sed -i.bak '/WSGIScriptAlias/ a WSGIPassAuthorization On' config.py
cwd: /opt/elasticbeanstalk/hooks
That will always work, even when changing environment variables. I hope you find it useful.
Edit: Seems like lots of people are still hitting this response. I haven't used ElasticBeanstalk in a while, but I would look into using Manel Clos' solution below. I haven't tried it personally, but seems a much cleaner solution. This one is literally a hack on EBs scripts and could potentially break in the future if EB updates them, specially if they move them to a different location.
Though the above solution is interesting, there is another way. Keep the wsgi.conf VirtualHost configuration file you want to use in .ebextensions, and overwrite it in a post deploy hook (you can't do this pre-deploy because it will get re-generated (yes, I found this out the hard way). If you do this, to reboot, make sure to use the supervisorctl program to restart so as to get all your environment variables set properly. (I found this out the hard way as well.)
cp /tmp/wsgi.conf /etc/httpd/conf.d/wsgi.conf
/usr/local/bin/supervisorctl -c /opt/python/etc/supervisord.conf restart httpd
exit 0
01_python.config:
05_fixwsgiauth:
command: "cp .ebextensions/wsgi.conf /tmp"

AWS No Environment found for EnvironmentName = 'name-env'

Why might I be seeing this error after I run git aws.push?
remote: error: Unable to deploy application version: No Environment found for EnvironmentName = 'reco-api-env'.
When I grep my flask app's directory for EnvironmentName, I see this:
./.elasticbeanstalk/config:6:EnvironmentName=name-env
./.git/AWSDevTools/aws/elastic_beanstalk_config.rb:36: :environment_name => "EnvironmentName",
I had similar symptoms when I manually updated default_region from us-west-2 to us-west-1. Reverting back fixed the issue.
I suspect you missed a step in the process. You need to use eb start before doing git aws.push.
I was using eb create to setup a new environment where the name differed from what I had started with in /.elasticbeanstalk/config.yml
Once I updated the environment reference to the one one I meant to target, eb commands started working as expected.
I had this issue too. For me, it was because I had outdated credentials in my ~/.aws/config file. Fixing that solved the problem.