JAX-RS 標準を使用して実装された REST API の許可と認証を提供する必要があります。これは、モバイル クライアントと一部のデバイスから使用されることを意図しています。一部のデータを POST できる一意のデバイス ID を持つ複数のデバイスがあります。モバイル クライアントは、GET 要求を使用してそのデータを表示しているだけです。クライアントを認証したい POST 部分についてもっと心配しています。また、シンプルにまとめたいと思います。API キーを使用して、HTTPS を介した単純な HTTP 基本認証を使用することを考えています。私の質問は、この API キーをどのように生成するのですか?
質問する
26605 次
4 に答える
2
これにはUUIDを使用できます。UUID は次のようになります。
550e8400-e29b-41d4-a716-446655440000
すべてのプログラミング言語で利用可能な UUID を生成するためのライブラリがあります。
于 2013-07-31T06:52:10.453 に答える
0
JAX-RS標準に依存し、アプリケーションを「純粋」に保ちたい場合は、コンテナに付属するデフォルトの認証システム（通常はBASIC認証）を使用します。
つまり、コンテナーは、標準に準拠し、回避策を構築しない (つまり、Shiro を使用する) Java EE アプリのように、認証とコース レベルの承認を実行する必要があります。
ただし、アプリケーションに認証システムを実装しないで API トークンなどの概念を使用したい場合は、その作業を別の場所、つまりコンテナーに実装する必要があります。
残念ながら、コンテナー ベースの認証はコンテナー固有のものでなければなりません。JAAS は、認証レルムを実行するための標準コンテナー API を記述していません。彼らのチュートリアルhttp://docs.oracle.com/javaee/6/tutorial/doc/bnbxj.htmlでも、 Glassfish 固有の構成について説明しています。
組織が十分に大きい場合、DataPower は OAuth http://www.ibm.com/developerworks/websphere/library/techarticles/1208_rasmussen/1208_rasmussen.htmlもサポートするため、おそらくそれを使用して認証を管理し、適切な資格情報をあなたの申請。でも。ベンダー固有の何かを行う必要があります。
ただし、これは悪いことではありません。アプリケーションを独自の認証システムで汚染して、認証システムが変更された場合に柔軟性が失われるよりも、むしろこのアプローチを採用したいと考えています。たとえば、SonarQube には、クライアント側の証明書をサポートしない独自の認証システムがあります。
于 2014-01-11T05:34:07.653 に答える