2

Django を Fronted として使用し、Celery をバックグラウンドで使用するアプリケーションを開発したいと考えています。現在、異なるマシン上の Celery ワーカーが、私の django フロントエンド マシン (2 つの異なるサーバー) へのデータベース アクセスを必要とする場合があります。彼らはいくつかのリアルタイムのことを知り、django-app を実行する必要があります

python manage.py celeryd 

すべてのモデルが利用可能なデータベースにアクセスする必要があります。

直接接続して MySQL データベースにアクセスする必要がありますか? したがって、フロントエンドマシンのローカルホストからだけでなく、他のワーカーサーバーIPからもユーザー「my-django-app」アクセスを許可する必要がありますか?

これは「正しい」方法ですか、それとも何か不足していますか? (sslなしでは)本当に安全ではないと思っていましたが、それが本来あるべき姿なのかもしれません。

ご回答ありがとうございます。

4

1 に答える 1

1

データベースにアクセスする必要があります。そのアクセスは、Django に同梱されているデータベース バックエンドまたはサード パーティのデータベース バックエンドを介して行われます。

私の Django サイトで行ったことの 1 つは、.xmlsettings.pyファイルからデータベース アクセス情報をロードすることです/etc。このように、アクセス設定 (データベース ホスト、ポート、ユーザー名、パスワード) はマシンごとに異なる可能性があり、パスワードなどの機密情報はプロジェクトのリポジトリにありません。ワーカーを別のユーザー名で接続させることにより、同様の方法でワーカーへのアクセスを制限したい場合があります。

また、環境変数を介して、データベース接続情報を渡したり、設定ファイルへのキーやパスだけを渡したり、settings.py.

たとえば、データベース構成ファイルを取り込む方法は次のとおりです。

g = {}
dbSetup = {}
execfile(os.environ['DB_CONFIG'], g, dbSetup)
if 'databases' in dbSetup:
    DATABASES = dbSetup['databases']
else:
    DATABASES = {
        'default': {
            'ENGINE': 'django.db.backends.mysql',
            # ...
        }
    }

言うまでもなくDB_CONFIG、データベース管理者と Django 自体以外のユーザーがファイルにアクセスできないようにする必要があります。デフォルトのケースでは、Django は開発者自身のテスト データベースを参照する必要があります。astの代わりにモジュールを使用するより良い解決策もあるかもしれexecfileませんが、まだ調査していません。

私が行うもう 1 つのことは、DB 管理タスクと他のすべてのタスクに別々のユーザーを使用することです。私のmanage.pyでは、次のプリアンブルを追加しました。

# Find a database configuration, if there is one, and set it in the environment.
adminDBConfFile = '/etc/django/db_admin.py'
dbConfFile = '/etc/django/db_regular.py'
import sys
import os
def goodFile(path):
    return os.path.isfile(path) and os.access(path, os.R_OK)
if len(sys.argv) >= 2 and sys.argv[1] in ["syncdb", "dbshell", "migrate"] \
    and goodFile(adminDBConfFile):
    os.environ['DB_CONFIG'] = adminDBConfFile
elif goodFile(dbConfFile):
    os.environ['DB_CONFIG'] = dbConfFile

構成は/etc/django/db_regular.py、SELECT、INSERT、UPDATE、および DELETE を使用して Django データベースのみにアクセスできるユーザー用であり、/etc/django/db_admin.pyこれらの権限に加えて CREATE、DROP、INDEX、ALTER、および LOCK TABLES を持つユーザー用です。(migrateコマンドはSouthからのものです。) これにより、実行時に Django コードが私のスキーマをいじるのを防ぐことができ、SQL インジェクション攻撃が引き起こす可能性のある損害を制限できます (ただし、すべてのユーザー入力をチェックしてフィルタリングする必要があります)。

これは正確な問題の解決策ではありませんが、目的に合わせて Django のデータベース アクセス設定をスマートにする方法についてのアイデアが得られるかもしれません。

于 2010-10-07T18:09:22.307 に答える