2017-10-16 4 views
0

私は社内で作成したいくつかのアプリケーションに基づいて新しい一連のアプリケーションを開始します。私の会社のアプリケーション(APIとSQLをホストするためにAzure Webアプリケーションも使用していました)では、ユーザーが1人しかいなかったため、クエリ結果を特定の方法で制限する必要はなく、ユーザーがデータにアクセスするリスクはありません彼らは持っていないはずだった。提供されたユーザーIDを持つ行へのEasy Tablesクエリの制限

しかし、これらのアプリケーションを外部で使用するように変更しているので、明らかに各ユーザーが各テーブルにアクセスする必要がある行を照会する必要があります。

最初のアイデアは、通常のEasyTableアクセスを許可しないようにすることでしたが、慎重に構築されたAPIを通してすべてを公開することができました。

このオプションは問題ありませんが、適切な場合、または各ユーザーが自分の行にしかアクセスできないようにしながら、通常のEasyTableアクセスを許可する方法があるかどうかはわかりません各テーブルに

答えて

1

Azure Active Directory、Facebook、Google、Twitter、Microsoftアカウント、またはその他のOAuthログインプロバイダに対して認証が設定されている場合は、特定の操作に対するアクセスを次のように制限するために、詳細については、レビューのためにHow to: Use authentication claims with your tables

enter image description here

ログインしたユーザーが自分のレコードだけを見ることができるようにデータを制限する方法については、really good tutorialをご覧ください。

+0

実際に私がやっていることではないにしても、あなたの答えは正しいとマークしています。私の場合、アイデンティティ・プロバイダーを使用したくないので、私が実際にやっていることの答えを投稿します。 – TKoL

+0

私はあなたの答えを直接使用していませんが、あなたが提供したリンクは、私が最後にどのように実装するかについての情報を与えました。ありがとう、たくさんの兄弟。 – TKoL

0

私の場合、私はIDプロバイダを使いたくないので、自分のアプリが電子メールアドレスに対して独自の認証を提供するようにしたい。

私は基本的に通常のOData APIによるアクセスを無効にするつもりのUserテーブルを用意します。ユーザーがメールアドレスとパスワードを入力できるAPIを提供します。一致する場合は、APIがその行のID(長いばかげた文字列)をフィードバックします。ユーザーアプリケーションは、そのIDを使用して他のテーブルにアクセスすることができます。

通常のOData APIを使用して他のすべてのテーブルにアクセスするには、I can use the 'context' object to look at HTTP headers。 HTTPSヘッダーが暗号化されていることを考えると、これは比較的安全な選択肢だと私は思っています。すべてのテーブルメソッドには、[${vendor-prefix}-UserID] = UserIDのようなHTTPヘッダーが必要です。

クライアント側では、しばしばMobileServiceClientライブラリ(allows addition of custom headers)を使用しますので、必要に応じてそこにヘッダを追加できます。

関連する問題