So here's my situation...I have two React apps that need to talk to the same Cognito User Pool. I've been able to accomplish this by copying the aws-exports.js file from the first app to the second app I created (not sure if this is something I should be doing or not but it is working). The issue I am having however is when I run an Admin Query on the second app (to say list users in the Cognito User Pool) I get a 403 (Forbidden) error. Has anyone ever run into this before? Googling all day has not helped me so I figured I would ask.
You'll need "multi-frontend" solution:
https://docs.amplify.aws/cli/teams/multi-frontend
I'll give you some useful infos for this:
Open the Amplify Console and there the "first" app (wheres the backend was created).
Go to the first app's "backend" section
Select "Backend environments" tab
Search for "Edit backend" box and this text: "To continue working on the backend, install the Amplify CLI and make updates by running the command below from the root of your project folder"
copy that command, and paste/run in second app's root.
Beware!
do not modify (and push) the backend from the second application.
if you use git branch based environment you must always switch the env AND the branch parallel. Do not pull the "master" backend for your "dev" env.
try to avoid modifing on amplify console if you modify things with amplify cli. Those things cannot be syncronized... :(
If you store multiple apps in a git monorepo:
https://docs.amplify.aws/cli/usage/monorepo
Related
My little podcast backend written in Django contains a ShowModel. I have also written a custom management command to update episodes for each show from an external API.
For ease of use I'd now like to put a button next to the list of shows in the Django admin to be able to update them from there. I know there's call_command() that also takes the argument but I'm getting a bit stuck in how to bring this into the admin area where the shows are already. Also, if possible I'd also pass the output to the web admin.
You can use this lib https://github.com/vint21h/django-mcadmin
Or try to read the code and pull some pieces to your project.
I was solving the same puzzle of running management commands from the admin interface, so here is what I found pip install -i https://test.pypi.org/simple/ django-run-command
This package helps you to run management commands from the admin dashboard
I have a deployment pipeline on Heroku which recently started using review apps. This means I have an app - let's call it CI-APP -- which is being created from the master branch.
Every time a pull request is made, a review app is created. We are using Django in our project and so I also added the migrate command to the release phase in the project, so that database migrations can be done automatically.
Today, a coworker submitted a pull request which contained some database changes. The problem is that the migration was ran, and since review apps seem to be using the same database as the app they are suppose to merge to, the migration was applied and now my app CI-APP stopped working...since the code base no longer matches the database structure.
I searched a lot about how to use completely different databases for the review apps compared to the parent app, but to no avail (there are some resources mentioning how you can copy db contents, but that is not what I need).
Any suggestion ?
Update
Ok, so it seems that Heroku does create a new database for the review app, however: the review app copies all of its environment variables from the parent, including the DATABASE_URL (this seems to be the only way to actually create the review app : https://s3.amazonaws.com/heroku-devcenter-files/article-images/1461071037-initial_set_up_review_apps.png)
I think I can do some black magic in the postdeploy script, but since the database generated url can be something such as HEROKU_POSTGRESQL_{color}_URL, I am not sure how to find it ....
To do that, create the app.json file at the root of your project instead of using the heroku dashboard. In this file, you can specify what environment variables to inherit from the parent.
From the heroku docs:
"env": {
"INHERIT_THIS_CONFIG_VAR": {
"required": true
},
"DONT_INHERIT_THIS_CONFIG_VAR": "production"
},
This allows you to specify which database you want to use for the review app. Looking at the documentation of the heroku postgres addon (i assume you're using postgres):
As part of the provisioning process, a DATABASE_URL config var is
added to your app’s configuration. This contains the URL your app uses
to access the database.
So the database_url config variable will be created by the adddon. You simply need to not put it in the app.json file, and it will be created automatically.
Check that you do not have the DATABASE_URL set in the Pipeline Settings CONFIG VARS in Heroku either.. if it is set there, then it seems the Review App will use that as the DB link and not the one created when the Review App is created.
I'm trying to build a Dockerized CouchDB to run in AWS that bootstraps authentication for my app. I've got a Dockerfile that installs CouchDB 1.6.1 and sets up the rest of the environment the way I need it. However, before I put it on AWS and potentially expose it to the wild, I want to put some authentication in place. The docs show this:
http://docs.couchdb.org/en/1.6.1/api/server/authn.html
which hardly explains the configuration properly or what is required for basic security. I've spent the afternoon reading SO questions, docs and blogs, all about how to do it, but there's no consistent story and I can't tell if what worked in 2009 will works now, or which parts are obsolete. I see a bunch of possible settings in the current ini files, but they don't match what I'm seeing in my web searches. I'm about to start trying various random suggestions I've gleaned from various readings, but thought I would ask before doing trial and error work.
Since I want it to run in AWS I need it to be able to start up without manual modifications. I need my Dockerfile to do the configuration, so using Futon isn't going to cut it. If I need to I can add a script to run on start to handle what can't be done there.
I believe that I need to set up an admin user, then define a role for users, provide a validation function that checks for the proper role, then create users that have that role. Then I can use the cookie authentication (over SSL) to restrict access to my app that provides the correct login and handles the session/cookie.
It looks like some of it can be done in the Dockerfile. Do I need to configure authentication_handlers, and an admin user in the ini file? And I'm guessing that the operations that modify the database will need to be done by some runtime script. Has anyone done this, or seen some example of it being done?
UPDATE:
Based on Kxepal's suggestion I now have it working. My Dockerfile is derived from klaemo's docker-couchdb, as mentioned below. The solution is to force the database to require authentication, but a fresh install starts out as Admin-Party. To stop that you have to create an admin user, which secures the system data but leaves other databases open. First, create an admin user in your Dockerfile:
RUN sed -e '/^\[admins\]$/a admin=openpassword\n' -i /usr/local/etc/couchdb/local.ini
(just following klaemo's sed pattern of using -e) and when CouchDB runs it will salt and hash this password and replace it in the local.ini file. I extract that password and replaced "openpassword" with this so that my Dockerfile didn't have the password in plain text. CouchDB can tell by the form of it not to hash it again.
The normal pattern to now secure the other databases is to create users/roles and use them in a validation function to deny access to the other databases. Since I am only interested in getting a secure system in place for testing I opted to defer this and just use the settings in local.ini to force everyone to be authenticated.
The Dockerfile now needs to set the require_valid_user flag:
RUN sed -e '/^\[couch_httpd_auth\]$/a require_valid_user = true\n' -i /usr/local/etc/couchdb/local.ini
And that requires uncommenting the WWW-Authenticate setting:
RUN sed -e 's/^;WWW-Authenticate/WWW-Authenticate/' -i /usr/local/etc/couchdb/local.ini
Which, since the setting shows Basic realm="administrator" means that the NSURLProtectionSpace in my iOS app needs to use #"administrator" as the realm.
After this I now have a Dockerfile that creates a CouchDB server that does not allow anonymous modification or reading.
This hasn't solved all of my configuration issues since I need to populate a database, but since I use a python script to do that and since I can pass credentials when I run that, I have solved most problems.
To setup auth configuration during image build, you need to check not API, but configuration for server admins. TL;DR just put [admin] section into local.ini file with your username and password in plain text - on start, CouchDB will replace password with it hash and CouchDB wouldn't be in Admin Party state.
P.S. Did you check docker-couchdb project?
I installed the https://github.com/pennersr/django-allauth package via pip. I followed the README.rst and after a bit of rigmarole got almost everything to work.
The facebook, twitter, openid and emailconfirmation sections are now appearing in my admin screen, but when I click on any of their menu items I get an error such as:
no such table: twitter_twitterapp
and a similar error for each of the four new apps. Did I miss a step or some steps in the installation process where the database tables get created?
I'm using sqlite3, if that has any bearing on the isssue.
If you have not already done syncdb then you must do that once. After doing that go in your admin and you will see a section for twitterapp and another for facebookapp. There you need to add the required keys.
I want to restrict access to all but a few selected files per a user, but if I type: /media/userdocuments/FILENAME django happily spits back the file for even users who aren't logged in. How can I integrate the permission framework to work around this?
Thanks!
EDIT: I realize that the django development server is insecure, so I guess the question is: How would I do that in a production environment with apache, lighttp, etc.
Use RewriteMap along with a script that connects to Django and verifies permissions, rewriting to a "disallowed" URL on auth failure.