質問編集履歴
4
タグ追加
test
CHANGED
|
File without changes
|
test
CHANGED
|
File without changes
|
3
タイトル修正
test
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
管理画面利用者とアプリ利用者の情報を同じテーブル
|
|
1
|
+
管理画面利用者の情報とアプリ利用者の情報を同じテーブルへ格納することについて
|
test
CHANGED
|
File without changes
|
2
タイトル修正
test
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
|
|
1
|
+
管理画面利用者とアプリ利用者の情報を同じテーブルに格納することについて
|
test
CHANGED
|
File without changes
|
1
本文修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
|
|
5
5
|
しかし、仮に会員制のアプリケーションを開発したとして、その利用者は、管理画面へのログインではなくアプリへのログインを目的としているかと思います。
|
|
6
6
|
|
|
7
|
-
ここで疑問ですが、DjangoではUserモデルを拡張する形での利用を推奨していますが、そもそも別のサイトへのログインである為、Userテーブル
|
|
7
|
+
ここで疑問ですが、DjangoではUserモデルを拡張する形での利用を推奨していますが、そもそも別のサイトへのログインである為、Userテーブルはアプリの利用者データを格納、UserAdminテーブルは管理画面へのログインユーザー情報を格納する、といった形で管理すべきはないかと思いました。
|
|
8
8
|
|
|
9
9
|
しかし、色々と調べていても、会員登録機能などでも、デフォルトのUserテーブルを使用する前提の認証機能などがほとんどであると感じました。
|
|
10
10
|
|