shunsuke0204
@shunsuke0204 (shunsuke)

Are you sure you want to delete the question?

If your question is resolved, you may close it.

Leaving a resolved question undeleted may help others!

We hope you find it useful!

DjangoのCustomUserの設計

解決したいこと

DjangoでWebアプリケーションを作成しています。
公式ドキュメントに従い、CustomUserを自分で設計しています。
その際のフィールドの設定で困っています。

最終的に目指している形

ユーザーは2種類用意したいと考えています。
1つ目は、管理者アカウントです。これは2つ目の一般アカウントを作成してその後管理する権限を持たせたいと考えています。
2つ目は、一般アカウントです。これは1つ目の管理者アカウントによって作成されたアカウントで、パスワードなどは自分で変更できますが、別の一般アカウントを作成することはできません。
管理者アカウントと一般アカウントは、OnetoManyで紐づいている状態が望ましいです。

また、別途開発者アカウントも用意したいです。
また、質問者(開発者)が管理者アカウントと一般アカウントの両方を、is_activeなどを用いて管理できるようにしたいと考えています。
開発者アカウントなしでも管理できそうですが、django標準のadminページが便利かなと思っています。

自分で試したこと・調べたこと

管理者アカウントをCustomUserとして、一般ユーザーは別にmodel.pyで設計をする。

CustomUserはAbstractUserとAbstractBaseUserがある。

柔軟性を考えて、CustomUserとしてAbstractBaseUserをユーザーモデルとして利用することにしました。

CustomUserは初回migrate前に作成しておく必要があること、またmigrate後はフィールドの編集が難しくなることが分かりました。

発生している問題

CustomUserを用いると、後からフィールドの編集をすることが面倒になり(方法は一応公式ドキュメントで見ました)、管理者アカウントに後から何かフィールドを追加する場合に困ってしまうと考えています。

設計案

上で試したことから
管理者アカウントのCustomUserモデルが最低限のユーザー情報(ユーザーID、ユーザー名、パスワード)を持ち、DetailTableモデルが詳細情報(メールアドレス、住所など)を持つようにすることを考えました。
CustomUserモデルとDetailTableモデルは、OneToOneFieldによって関連付けをすることで、DetailTableを編集することで、後から要素の追加が容易にできるようになるのではないかと考えています。

質問

以上の設計で問題ないのか、また別の方法で設計したほうが良いなどがあれば教えてください。
初学者ですので、表現や知識に誤りがあればそれについても指摘を頂けると嬉しいです。

0

2Answer

私は認証プロセスと業務プロセスを分離するべきと考えています。

browserーnginxーuwsgiーdjangoーappl
      |        |
     ldapーーーーーーー+

の構成の場合、nginxでldap/basic認証を担い、djangoではadmin,user等のサブディレクトリで区分するか?httpヘッダーのユーザ名から、再度、ldap検索して、権限、ロールを取得、判定します。

sslなんかも、nginxが担う方がアプリ作成が楽になる様なものです。

0Like

Comments

  1. @shunsuke0204

    Questioner

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

    nginxに認証機能を持たせることが解決策にあるのですね。
    roleごとのディレクトリを用意して、特定のディレクトリへのアクセスを許可するということでしょうか?
    その場合、djangoのモデル設計はどのようにすべきなのでしょうか?

  2. djangoのモデル設計は純粋にサブディレクトリを意識したものでOKです。
    しかし、共通ディレクトリなら、httpヘッダーのBasic認証のユーザ名を取得して、Ldapからロール、権限を取得します。このロジックは貴方の自由なロジックです。

  3. @shunsuke0204

    Questioner

    ありがとうございます。ldapについて全くもって知識がありませんでしたので、質問も稚拙になっていたと思います。 DBのアカウントに特化したものとして今は考えています。
    今後ldapについても学習をすることにしたのですが、今回のモデル設計に問題がないのであれば、質問文にある設計で一度作成をしてみたいと考えています。ldapを用いない前提で質問文の設計ですと、何か問題は発生しそうでしょうか。もし知見がありましたら、ご教示いただきたいです。

  4. 今回のモデル設計に問題がないのであれば、質問文にある設計で一度作成をしてみたい

    問題はありません。思想、プロセスの違いで結果は同じレベルです。

    但し、参考サンプルは身の丈に合った簡単なコードを探してはどうでしょう。

    私は古代のwsgiをベースにしてwebプログラミングをしていますが、この前、wsgiのミドルウェアから、django,flaskを呼び出してdjango,flaskを比較したのですが、学習曲線は明らかにflaskが高いと実感しました。

    DB対応で、プロジェクト管理が簡単()なdjangoですが、学習曲線が低く習得に時間を要するかもしれません。

    個人的な学習ならflaskもご検討下さい。DB機能がないですが、

  5. @shunsuke0204

    Questioner

    なるほど、ありがとうございます。
    flaskは一度触ったことがあり、djangoと比べると、SQLを自分で書くflaskの方が動作がわかりやすいと感じました。おっしゃる通り、学習もスムーズに進んだ印象があります。

    開発しているものが最終的には個人的に利用するのではなく、他の方々にも使っていただけるサービスにしたいと考えています。
    技術選定をするにも、経験が浅いと悩む部分が多いと感じます。
    精進します。

AbstractBaseUserとallauthで通常通りユーザーモデルを作成して、「管理者アカウントと一般アカウントは、OnetoManyで紐づいている状態が望ましい」の部分は、チームのようなモデルを作ることで解決しそうな気もしますがどうですか?

models.py
class User(models.Model):
    # 省略

class Teams(models.Model):
    owner = models.ForeignKey(User, on_delete=models.CASCADE)
    member = models.ManyToManyField(User, blank=True

みたいな感じ?

0Like

Your answer might help someone💌