質問編集履歴
7
文言修正
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -24,8 +24,7 @@
|
|
|
24
24
|
|
|
25
25
|
###ユーザーのパスワード管理の仕方
|
|
26
26
|
|
|
27
|
-
私は、基本的に
|
|
27
|
+
私は、基本的にOpenIDによるID連携は使いません。
|
|
28
|
-
下手にアクセス権限などを与えたくないからです。
|
|
29
28
|
（不意に、本名、プロフィール写真が出たり、メールアドレスがバレたりなど）
|
|
30
29
|
|
|
31
30
|
こうした設計になった理由として考えられるのは、「1ID、1パスワードだけだと、もしIDパスワードが流出したら、全てのチームにアクセスできてしまい危険。」という理由だけでしょうか？
|
6
文言追加
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -69,4 +69,6 @@
|
|
|
69
69
|
> クライアントから見たら、「同じチームの中に、よその全く知らない会社の人がいる」ってなってしまいますもんね？
|
|
70
70
|
|
|
71
71
|
「チーム」を、LINEのグループのような捉え方をしていたので、そこから間違ってました。
|
|
72
|
-
有償プラン入らないと、Slackを理解できなさそうというのが、結論だったっぽいです。
|
|
72
|
+
有償プラン入らないと、Slackを理解できなさそうというのが、結論だったっぽいです。
|
|
73
|
+
|
|
74
|
+
SAML認証って何…
|
5
文言追加
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -68,4 +68,5 @@
|
|
|
68
68
|
> 1プロジェクトに2～3チャンネルずつくらい割り当てて、一つのチームだけでやっていくのは、難しいですよね？
|
|
69
69
|
> クライアントから見たら、「同じチームの中に、よその全く知らない会社の人がいる」ってなってしまいますもんね？
|
|
70
70
|
|
|
71
|
+
「チーム」を、LINEのグループのような捉え方をしていたので、そこから間違ってました。
|
|
71
72
|
有償プラン入らないと、Slackを理解できなさそうというのが、結論だったっぽいです。
|
4
文言追加
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -55,4 +55,17 @@
|
|
|
55
55
|
|
|
56
56
|
「パスワード入れなくていいから、メールに送ったリンクから入ってね」というのは、今後、流行ると思いますか？
|
|
57
57
|
|
|
58
|
-
Slack自体を、まだ理解しておりませんので、的外れな所があるかもしれませんが、よろしくお願いします。
|
|
58
|
+
Slack自体を、まだ理解しておりませんので、的外れな所があるかもしれませんが、よろしくお願いします。
|
|
59
|
+
|
|
60
|
+
###追記
|
|
61
|
+
「チームの作り方」について、間違った認識でいました。
|
|
62
|
+
いただいた回答のやり取りの中で、有償プランについて出てきて、それ見て納得できました。
|
|
63
|
+
|
|
64
|
+
> Slackの利用については、いくつか協業している会社をまたいで、プロジェクト毎にチームを作っていけたらなと思っていましたが、認証の所で、尻込みしてしまいました。
|
|
65
|
+
>
|
|
66
|
+
> プロジェクト毎に、毎回ほぼメンバーが同じ、5人中4人が同じで、残り一人がそれぞれ違う。つまりは「クライアントが変わる」のですが、それで毎回チームを作っていくのは変ですか？
|
|
67
|
+
>
|
|
68
|
+
> 1プロジェクトに2～3チャンネルずつくらい割り当てて、一つのチームだけでやっていくのは、難しいですよね？
|
|
69
|
+
> クライアントから見たら、「同じチームの中に、よその全く知らない会社の人がいる」ってなってしまいますもんね？
|
|
70
|
+
|
|
71
|
+
有償プラン入らないと、Slackを理解できなさそうというのが、結論だったっぽいです。
|
3
文言追加
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -47,7 +47,7 @@
|
|
|
47
47
|
|
|
48
48
|
なぜ、このような設計になったと考えられますか？
|
|
49
49
|
|
|
50
|
-
1ID、1パスワードで全てのチームにアクセスできるのは、不都合でしょうか？
|
|
50
|
+
1ID、1パスワードで自分の所属する（招待された）全てのチームにアクセスできるのは、不都合でしょうか？
|
|
51
51
|
|
|
52
52
|
さまざまなサードパーティーアプリと連携するには、この方が好都合なんだよとかいう、何か理由があれば、伺いたいです。
|
|
53
53
|
|
2
文言追加
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -41,6 +41,8 @@
|
|
|
41
41
|
|
|
42
42
|
まぁ、ユーザー認証の歴史は、紆余曲折ありますので、楽しんで見てます。
|
|
43
43
|
|
|
44
|
+
「アクセシビリティ」と「セキュリティー」のタグを付けましたが、その両者のせめぎ合いという普遍的なテーマであるようにも思いますが、このアプローチは、「なんか違うんじゃないか」という気がしています。
|
|
45
|
+
|
|
44
46
|
###伺いたい事
|
|
45
47
|
|
|
46
48
|
なぜ、このような設計になったと考えられますか？
|
1
文言追加
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -26,6 +26,7 @@
|
|
|
26
26
|
|
|
27
27
|
私は、基本的にOAuth認証によるID連携は使いません。
|
|
28
28
|
下手にアクセス権限などを与えたくないからです。
|
|
29
|
+
（不意に、本名、プロフィール写真が出たり、メールアドレスがバレたりなど）
|
|
29
30
|
|
|
30
31
|
こうした設計になった理由として考えられるのは、「1ID、1パスワードだけだと、もしIDパスワードが流出したら、全てのチームにアクセスできてしまい危険。」という理由だけでしょうか？
|
|
31
32
|
|