因此，我開始了一系列新的應用程序的基礎上我爲我的公司內部的一些應用程序。使用我公司的應用程序（我也使用Azure Web應用程序來託管API和SQL），因此我不必以任何特定的方式限制查詢結果，因爲只有1個用戶，所以沒有任何用戶訪問數據的風險他們不應該有。限制簡易表查詢行與提供的用戶ID
但是現在我正在修改這些應用程序以供外部使用，我顯然只希望每個用戶都可以查詢每個表，查找他們應該有權訪問的行。
我的第一個想法是根本不允許普通的EasyTable訪問，但只是通過精心構建的API公開所有的API，每個API都需要一個UserID作爲參數才能工作。
這個選項對我來說很好，但我不確定是否正確，或者仍然允許普通的EasyTable訪問，同時仍然允許每個用戶只能訪問自己的行在每張桌子上。
如果您已針對Azure Active Directory，Facebook，Google，Twitter，Microsoft帳戶或其他OAuth登錄提供程序設置了身份驗證，則可以對錶設置權限以將特定操作的訪問權限限制爲僅限經過身份驗證的用戶，如下所示：
欲瞭解更多信息，審覈How to: Use authentication claims with your tables。
關於如何限制數據，以便登錄用戶只能看到他們的記錄，看看這really good tutorial。
在我的情況下，我不想使用身份提供商，我希望我的應用根據電子郵件地址提供自己的身份驗證。
我將要有一個用戶表，我將基本上只是通過正常的OData API禁止訪問。我將提供一個用戶可以提供電子郵件地址和密碼的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，所以我可以在需要時添加標頭。
即使我不打算在練習中做什麼，我仍然將您的答案標記爲正確。我會發布我實際要做的事情的答案，因爲我不想在我的情況下使用身份提供商。 – TKoL
順便說一句，即使我沒有直接使用你的答案，你提供的這些鏈接提供了一個關於我將如何實施它的最終信息。非常感謝兄弟。 – TKoL