This is probably not the main reason why the create_all()
method call doesn’t work for people, but for me, the cobbled together instructions from various tutorials have it such that I was creating my db in a request context, meaning I have something like:
# lib/db.py
from flask import g, current_app
from flask_sqlalchemy import SQLAlchemy
def get_db():
if 'db' not in g:
g.db = SQLAlchemy(current_app)
return g.db
I also have a separate cli command that also does the create_all:
# tasks/db.py
from lib.db import get_db
@current_app.cli.command('init-db')
def init_db():
db = get_db()
db.create_all()
I also am using a application factory.
When the cli command is run, a new app context is used, which means a new db is used. Furthermore, in this world, an import model in the init_db method does not do anything, because it may be that your model file was already loaded(and associated with a separate db).
The fix that I came around to was to make sure that the db was a single global reference:
# lib/db.py
from flask import g, current_app
from flask_sqlalchemy import SQLAlchemy
db = None
def get_db():
global db
if not db:
db = SQLAlchemy(current_app)
return db
I have not dug deep enough into flask, sqlalchemy, or flask-sqlalchemy to understand if this means that requests to the db from multiple threads are safe, but if you’re reading this you’re likely stuck in the baby stages of understanding these concepts too.
The first comment nailed the most likely reason this is happening. Quoting the release announcement:
PostgreSQL 15 also revokes the
CREATE
permission from all users except a database owner from thepublic
(or default) schema.
The reason your fix didn’t work is that all actions you took on database postgres
in regards to user admin
‘s privileges on schema public
concern only that schema within the database postgres
. Schema public
on database postgres
is not the same schema public
as the one on newly created mydb
.
Also, this:
GRANT ALL ON DATABASE mydb TO admin;
grants privileges on the database itself, not things within the database. admin
can now drop the database, for example, still without being able to create tables in schema public
. My guess is that you wanted to make admin
also the owner of mydb
, in which case you need to add
ALTER DATABASE mydb OWNER TO admin;
Or you need to repeat your GRANT USAGE, CREATE ON SCHEMA public TO admin;
on mydb
.
Here’s some more documentation on secure schema usage patterns the PostgreSQL 15 change was based on.
I kept getting this error when using flyway
to deploy database changes. I do some manual setup first, such as creating the database, so flyway wouldn’t need those super-admin permissions.
My Fix
I had to ensure that the database user that flyway job used had ownership rights to the public schema, so that the flyway user could then assign the right to use the schema to other roles.
Additional setup Details
I am using AWS RDS (both regular and Aurora), and they don’t allow super users in the databases. RDS reserves super users for use by AWS, only, so that consumers are unable to break the replication stuff that is built in. However, there’s a catch-22 that you must be an owner in postgres to be able to modify it.
My solution was to create a role that acts as the owner (‘owner role’), and then assign both my admin user and the flyway user to the owner role, and use ALTER
scripts for each object to assign the object’s owner to the owner role.
I missed the public schema, since that was auto-created when I created the database script manually. The public schema defaulted to my admin role rather than the shared owner role. So when the flyway user tried to assign public schema permissions to other roles, it didn’t have the authority to do that. An error was not thrown during flyway execution, however.
I kept getting this error when using flyway
to deploy database changes. I do some manual setup first, such as creating the database, so flyway wouldn’t need those super-admin permissions.
My Fix
I had to ensure that the database user that flyway job used had ownership rights to the public schema, so that the flyway user could then assign the right to use the schema to other roles.
Additional setup Details
I am using AWS RDS (both regular and Aurora), and they don’t allow super users in the databases. RDS reserves super users for use by AWS, only, so that consumers are unable to break the replication stuff that is built in. However, there’s a catch-22 that you must be an owner in postgres to be able to modify it.
My solution was to create a role that acts as the owner (‘owner role’), and then assign both my admin user and the flyway user to the owner role, and use ALTER
scripts for each object to assign the object’s owner to the owner role.
I missed the public schema, since that was auto-created when I created the database script manually. The public schema defaulted to my admin role rather than the shared owner role. So when the flyway user tried to assign public schema permissions to other roles, it didn’t have the authority to do that. An error was not thrown during flyway execution, however.
In Postgres I created the following table inside a db called testing
:
CREATE TABLE category_google_taxonomy (
category_id integer references category ON UPDATE CASCADE ON DELETE CASCADE,
google_taxonomy_id integer references google_taxonomy ON UPDATE CASCADE ON DELETE CASCADE
);
When I try to populate the table:
INSERT INTO category_google_taxonomy (category_id, google_taxonomy_id) VALUES
(1,7),
(2,12);
I get the following error:
ERROR: permission denied for schema public
LINE 1: SELECT 1 FROM ONLY "public"."category" x WHERE "category_id"...
^
QUERY: SELECT 1 FROM ONLY "public"."category" x WHERE "category_id" OPERATOR(pg_catalog.=) $1 FOR SHARE OF x
I read up a bit and eventually granted ALL PRIVILEGES
out of exasperation, but it still doesn’t work:
testing=# GRANT ALL PRIVILEGES ON public.category TO testing;
GRANT
testing=# dp category_google_taxonomy
Access privileges
Schema | Name | Type | Access privileges | Column access privileges
--------+--------------------------+-------+-------------------------+--------------------------
public | category_google_taxonomy | table | testing=arwdDxt/testing |
: super=arwdDxt/testing
testing=# dp category
Access privileges
Schema | Name | Type | Access privileges | Column access privileges
--------+----------+-------+------------------------+--------------------------
public | category | table | testing=arwdDxt/super | category_id:
: testing=arwx/super
(1 row)
On @Daniel’s suggestion I tried GRANT USAGE ON schema public TO super;
, now when I run the INSERT
command I get:
ERROR: permission denied for relation category
CONTEXT: SQL statement "SELECT 1 FROM ONLY "public"."category" x WHERE "category_id" OPERATOR(pg_catalog.=) $1 FOR SHARE OF x"
Here is the relevant part of d
:
public | category | table | super
public | category_google_taxonomy | table | testing
Я запускаю Postgres 10.4 и в настоящее время сбит с толку, поскольку не могу предоставить доступ к схеме другой роли.
Что я хочу сделать:
У меня одна роль с одной схемой, и я хочу получить доступ к схеме и ее таблицам из другой роли. Итак, я сделал как обычно (что работало с другими схемами):
grant usage on schema myschema to newuser;
grant select on all tables in schema myschema to newuser;
Оба этих оператора выполнялись как владелец схемы. При этом я не столкнулся с какими-либо ошибками.
Когда я вхожу в систему как новый пользователь и пытаюсь выбрать некоторые данные:
select * from myschema.table;
Я получаю сообщение об ошибке:
SQL Error [42501]: ERROR: permission denied for schema myschema
Я вижу, что у нового пользователя есть нужные привилегии в таблице «information_schema.role_table_grants»
Он также работал с другой ролью и другой схемой. Я невежественен.
Ответы
2
Это определенно работает, как указано в моем вопросе, проблема заключалась в том, что я не использовал владельца схемы.
Поэтому всегда убедитесь, что вы предоставляете доступ к схеме от роли владельца.
Шаг 1
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA name_schema TO name_user;
Шаг 2
GRANT USAGE ON SCHEMA name_schema TO name_user;
Другие вопросы по теме
NataNov 0 / 0 / 0 Регистрация: 09.04.2021 Сообщений: 4 |
||||||||||||
1 |
||||||||||||
Создание пользователя с правами на таблицы в схеме09.04.2021, 14:54. Показов 4679. Ответов 1 Метки нет (Все метки)
Добрый день!
Затем подключаюсь к базе my_db под пользователем user1: c my_db user1 До сих пор все шло прекрасно. Но дальше пытаюсь сделать select от имени пользователя user1:
выходит ошибка — нет доступа к схеме my_schema пытаюсь по другому:
Ошибка — нет доступа к таблице my_table! Что я делаю не так?!
__________________ 0 |
grgdvo 1184 / 914 / 367 Регистрация: 02.09.2012 Сообщений: 2,785 |
||||
10.04.2021, 09:09 |
2 |
|||
Сообщение было отмечено NataNov как решение Решение Схема — такой же объект базы, как и таблицы.
1 |
Допустим, я сделал эту «простую» реализацию БД в Postgres.
postgres=# CREATE ROLE my_role;
CREATE DATABASE my_db;
GRANT ALL ON DATABASE my_db TO my_role;
CREATE SCHEMA my_schm AUTHORIZATION my_role;
А потом я хочу сделать таблицу:
postgres=#CREATE TABLE IF NOT EXIST my_db.my_schm.table(...);
И получил следующую ошибку: cross-database references are not implemented: "my_db.my_schm.table"
После этого я попытался создать таблицу, подключенную к базе данных (т.е. c my_db
), и получил следующую ошибку:
schema "my_schm"does not exist
Итак, я не понимаю поведения этих ошибок. Предполагается, что роль имеет все разрешения для базы данных (и да, я также пробовал использовать SET ROLE my_role;
), но когда я прошу показать схемы в my_db действительно my_schm не существует, но в Postgres он есть. Может кто-нибудь объяснить мне, пожалуйста, почему это происходит? А также как сгруппировать таблицы в my_schm?
1 ответ
Лучший ответ
Схемы существуют только в одной базе данных и создаются в текущей базе данных: вы создали свою схему в базе данных postgres
, а не в mydb
.
Вам необходимо сначала подключиться к базе данных mydb
, чтобы создать схему в базе данных mydb
.
3
pifor
24 Май 2020 в 10:56
|
|
|
информация о разделе
Данный раздел предназначается исключительно для обсуждения вопросов использования языка запросов SQL. Обсуждение общих вопросов, связанных с тематикой баз данных — обсуждаем в разделе «Базы данных: общие вопросы». Убедительная просьба — соблюдать «Правила форума» и не пренебрегать «Правильным оформлением своих тем». Прежде, чем создавать тему, имеет смысл заглянуть в раздел «Базы данных: FAQ», возможно там уже есть ответ. |
разные пользователи и доступ
, не могу разобраться с ролями
- Подписаться на тему
- Сообщить другу
- Скачать/распечатать тему
|
|
Senior Member Рейтинг (т): 13 |
Здравствуйте, Господа!
#psql postgres=# CREATE USER user1 WITH password ‘password’; postgres=# CREATE DATABASE db1; postgres=# GRANT ALL PRIVILEGES ON DATABASE db1 TO user1; postgres=# CREATE USER user2 WITH password ‘password’; postgres=# GRANT ALL PRIVILEGES ON DATABASE db1 TO user2; postgres=# q #psql -U user1 db1 db1=# CREATE SEQUENCE user_ids; db1=# CREATE TABLE users (id INTEGER PRIMARY KEY DEFAULT NEXTVAL(‘user_ids’), login CHAR(64), password CHAR(64)); db1=# INSERT INTO users (login, password) VALUES («u1», «p1»); db1=# q #psql -U user2 db1 db1=# INSERT INTO users (login, password) VALUES («u2», «p2»); ОШИБКА: нет доступа к отношению users Вот тут я в растерянности. Оба пользователя ALL PRIVILEGES для db1, но второй, т.е. не создатель таблицы, добавлять записи не может. |
grgdvo |
|
Member Рейтинг (т): 21 |
Опция ALL PRIVILEGES для DATABASE подразумевает CREATE, CONNECT и кажется TEMP привилегии для базы данных. |
HighMan |
|
Senior Member Рейтинг (т): 13 |
Цитата grgdvo @ 14.10.15, 12:36 Опция ALL PRIVILEGES для DATABASE подразумевает CREATE, CONNECT и кажется TEMP привилегии для базы данных. Простите бестолкового, а как для схем предоставить привилегии? Сообщение отредактировано: HighMan — 14.10.15, 14:58 |
grgdvo |
|
Member Рейтинг (т): 21 |
Цитата HighMan @ 14.10.15, 14:57 Простите бестолкового, а как для схем предоставить привилегии?
В конце я неправ, забываешь как оно работает, когда не пользуешься. Нужны команды конкретно на таблицу или ALL TABLES IN SCHEMA. Для вашего примера скорее всего правильный порядок будет такой
~ # psql -U postgres postgres=# CREATE USER user1 WITH password ‘password’; postgres=# CREATE USER user2 WITH password ‘password’; postgres=# CREATE DATABASE db1; postgres=# q db1 создается со схемой public по умолчанию, в которой пользователи уже могут создавать таблицы (и т.д.), поэтому user1 и user2 смогут создать свои объекты базы
~ # psql -U user1 db1 db1=# CREATE SEQUENCE user_ids; db1=# CREATE TABLE users (id INTEGER PRIMARY KEY DEFAULT NEXTVAL(‘user_ids’), login CHAR(64), password CHAR(64)); db1=# INSERT INTO users (login, password) VALUES (‘u1’, ‘p1’); db1=# q теперь к user_ids и users доступ имеет только user1, ибо он владелец этих объектов.
~ # psql -U postgres db1 db1=# GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO user2; db1=# GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO user2; Теперь user2 имеет все привилегии на таблицы и последовательнсти, которые УЖЕ БЫЛИ СОЗДАНЫ на данный момент в схеме.
~ # psql -U user2 db1 db1=# INSERT INTO users (login, password) VALUES (‘u2’, ‘p2’); Сообщение отредактировано: grgdvo — 14.10.15, 20:28 |
HighMan |
|
Senior Member Рейтинг (т): 13 |
Цитата grgdvo @ 14.10.15, 20:28 Цитата HighMan @ 14.10.15, 14:57 Простите бестолкового, а как для схем предоставить привилегии?
В конце я неправ, забываешь как оно работает, когда не пользуешься. Нужны команды конкретно на таблицу или ALL TABLES IN SCHEMA. Для вашего примера скорее всего правильный порядок будет такой
~ # psql -U postgres postgres=# CREATE USER user1 WITH password ‘password’; postgres=# CREATE USER user2 WITH password ‘password’; postgres=# CREATE DATABASE db1; postgres=# q db1 создается со схемой public по умолчанию, в которой пользователи уже могут создавать таблицы (и т.д.), поэтому user1 и user2 смогут создать свои объекты базы
~ # psql -U user1 db1 db1=# CREATE SEQUENCE user_ids; db1=# CREATE TABLE users (id INTEGER PRIMARY KEY DEFAULT NEXTVAL(‘user_ids’), login CHAR(64), password CHAR(64)); db1=# INSERT INTO users (login, password) VALUES (‘u1’, ‘p1’); db1=# q теперь к user_ids и users доступ имеет только user1, ибо он владелец этих объектов.
~ # psql -U postgres db1 db1=# GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO user2; db1=# GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO user2; Теперь user2 имеет все привилегии на таблицы и последовательнсти, которые УЖЕ БЫЛИ СОЗДАНЫ на данный момент в схеме.
~ # psql -U user2 db1 db1=# INSERT INTO users (login, password) VALUES (‘u2’, ‘p2’);
Спасибо большое! |
0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
0 пользователей:
- Предыдущая тема
- Базы данных: SQL
- Следующая тема
[ Script execution time: 0,0347 ] [ 15 queries used ] [ Generated: 30.01.23, 08:58 GMT ]
Пытаюсь запустить flask и postgresql в контейнере, но успешно запускается только postgresql, а flask падает с ошибкой:
Traceback (most recent call last):
File "/app/app.py", line 12, in <module>
db.create_all()
*Обновление* Вне докера тоже вылетает данная ошибка
Вот мои файлы:
models.py
from datetime import datetime
import flask_sqlalchemy
db = flask_sqlalchemy.SQLAlchemy()
class Quiz(db.Model):
__tablename__ = 'quiz'
id = db.Column(db.Integer, primary_key=True)
question = db.Column(db.String(255))
answer = db.Column(db.String(100))
created = db.Column(db.DateTime, default=datetime.utcnow)
def __repr__(self):
return f"id: {self.id}, answer: {self.answer}, created: {self.created}"
app.py
import json
from flask import Flask, request
from models import db
import config
app = Flask(__name__)
app.config['SQLALCHEMY_DATABASE_URI'] = config.DATABASE_CONNECTION_URI
app.config['SQLALCHEMY_TRACK_MODIFICATIONS'] = False
app.app_context().push()
db.init_app(app)
db.create_all()
# @app.route('/', methods=['GET'])
@app.route('/')
def hello_world():
return 'Flask Dockerized!'
config.py
import os
user = "tzuser"
password = "password"
host = "postgres"
database = "tzdb"
port = "5432"
DATABASE_CONNECTION_URI = f'postgresql+psycopg2://{user}:{password}@{host}:{port}/{database}'
Dockerfile
FROM python:3.10
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
ENTRYPOINT ["python"]
CMD ["app.py"]
docker-compose.yml
version: '3.9'
services:
app:
build:
context: ./app
ports:
- 5000:5000
volumes:
- ./app:/app
postgres:
image: postgres:13.3
healthcheck:
test: [ "CMD", "pg_isready", "-q", "-d", "postgres", "-U", "tzuser" ]
timeout: 45s
interval: 10s
retries: 10
restart: always
environment:
POSTGRES_DB: tzdb
POSTGRES_USER: tzuser
POSTGRES_PASSWORD: password
ports:
- 5432:5432
volumes:
# - ./db.sql:/docker-entrypoint-initdb.d/db.sql
# - ./postgres-data:/var/lib/postgresql/data
- ./db-data/:/var/lib/postgresql/data/
# - ./init.sql:/docker-entrypoint-initdb.d/init.sql
database sqlite
To avoid errors while passing a single quote (‘) in a SQLite query, you can use SQL parameters.
Here is an example code:
import sqlite3
# connect to database
conn = sqlite3.connect('example.db')
c = conn.cursor()
# example query with parameter
query = "SELECT * FROM my_table WHERE name = ?"
# parameter to be passed in query
name_with_quote = "John O'Connor"
# execute the query with parameter
c.execute(query, (name_with_quote,))
# fetch the result
result = c.fetchall()
# print the result
print(result)
# close the connection
conn.close()
In this example, we use a parameter name_with_quote
which contains a single quote. Instead of directly passing the parameter in the query string, we use a ?
placeholder in the query. Then we pass the parameter as a tuple in the execute
method. This way, the parameter is sanitized and any special character is properly escaped.
To summarize my problem, I try to generate my PostgreSQL database tables with the SQLAlchemy command db.create_all() and it returns the following error:
RuntimeError: No application found. Either work inside a view function or push an application context. See http://flask-sqlalchemy.pocoo.org/contexts/.
I have of course followed the documentation and threads on this platform and tried different alternatives:
from app import db, create_app
db.create_all()
This approach still fails with the same message. Another alternative was to include the create_app function inside the create_all() function so that it would have the correct context.
db.create_all(app=create_app())
This generated a new error because when the create_app() function is executed, it needs environment variables (I don’t know how to include the variables through the python terminal).
db.init_app(app)
with app.app_context():
db.create_all()
migrate.init_app(app, db)
mail.init_app(app)
The result of this execution is NOTHING. Absolutely nothing happens inside the database, I am 100% sure that there is connectivity between my run and my database but no table or any kind of error is generated.
Of all the alternatives I think the most reasonable is to run the creation through the python terminal, however, I have the problem of environment variables that I already include by powershell when I run my application but it does not help me to initialize the database from the terminal.
Could someone give me some hint or help in some direction?
Solution
Greetings to everyone who has been interested in this thread and special thanks to mechanical_meat for his support and assistance.
I have learned a lot about python applications and the reasons why my application was failing. First of all I think that to understand the solution it is necessary that I comment my project structure:
├── entrypoint.py
├── config
├── app
│ ├── __init__.py
│ │ └── models.py
│ ├── module 1
│ │ └── models.py
│ ├── module 2
│ ├── module N
│ │ └── models.py
In case I needed to launch my application, I activated my virtual environment and added the necessary environment variables (FLASK_ENV, FLASK_APP or APP_SETTINGS_MODULE).
At this point if I try to run db.create_all() I get the error from this thread that the application context does not exist as only the following lines exist within my entrypoint:
from flask import send_from_directory
import os
from app import create_app
settings_module = os.getenv('APP_SETTINGS_MODULE')
app = create_app(settings_module)
if __name__ == '__main__':
app.run(debug=True)
My solution in this case has been a silly one. The only thing I have done is to create two python files at the same height as my entrypoint. The first one contains information similar to my app generator but with the difference that all the variables in it are initialised with the configurations (from a security point of view it’s a bad approach):
from flask import Flask
from flask_login import LoginManager
from flask_sqlalchemy import SQLAlchemy
app = Flask(__name__)
app.config['SECRET_KEY'] = 'SECRET'
app.config['SQLALCHEMY_DATABASE_URI'] = 'postgresql://postgres:...'
app.config['SQLALCHEMY_TRACK_MODIFICATIONS'] = False
login_manager = LoginManager(app)
login_manager.login_view = "login"
db = SQLAlchemy(app)
from models_db import User, Task, History
The other file includes the declaration of the classes to load the columns correctly. And, with this solution the generation of the database tables has worked, the only additional change has been to change the environment variable from app to my new class that is in charge of creating the DB. This is necessary because my goal is that it can be included in a dockerfile and the tables are created automatically.
I reiterate my thanks to all of you who have bothered to read this thread, if anyone has a more elegant solution I will be happy to analyse it in depth. If this can help someone else to reach a solution that would be great.
Answered By — Buscatrufas
Answer Checked By — Terry (WPSolving Volunteer)