約 14,852 件
https://w.atwiki.jp/pcmbeta/pages/32.html
個人用途でiSCSI接続認証を設定する目的solarisのZFSボリュームをiSCSIターゲットとして公開し、VMwareやHyper-Vから利用する場合に、うっかりボリュームを別形式でフォーマットしてしまう誤操作を防止する。VMware ESXi 4は、ボリュームをマウントする際、VMFSとして認識できないとき(NTFSなど)にはユーザー確認を出すことなく、無条件でVMFS形式でフォーマットしてしまう。 ターゲット側で、接続してくるイニシエーターを限定すれば、ある程度この誤操作を防止することができる。 認証の方式solaris 10のiSCSIターゲットには、接続するiSCSIイニシエーターを限定する仕組みとして、ACL機能とCHAP認証機能が備わっている。マニュアル iscsitadmコマンド説明(英語) @ docs.sun ACL機能は、iSCSI接続を、決められた名前のイニシエーターだけに限定する。 CHAP機能は、iSCSI接続を、交わす秘密鍵が一致するイニシエーターだけに限定する。マニュアル iSCSI ターゲットの CHAP 認証を構成する方法 @ docs.sun どちらの方式も、ターゲット側は公開するボリューム毎に設定できるが、イニシエーター側はホスト単位で設定することになる。VMwareとHyper-Vの混同を避ける目的には、ホスト(ハイパーバイザー)単位で別のものを指定できるため、有効に働く。 同じVMware ESXiホスト上で、VMFSボリュームとRDM(Raw Device Mapping)ボリュームを誤ってマウントしない目的には、使えない。名前(iqn)もCHAP秘密鍵も、同じホストである限り、VMFSとRDMで共通の値になってしまうからである。 個人の誤操作を防止する用途では、CHAPまでは不要で、ACLだけ設定すれば十分と思われる。 ★ACLの設定準備/イニシエーター側 (VMware、Hyper-V) iqn名を定める。イニシエーター側ドライバーが勝手に定めるデフォルト値は、再インストールやアップデートをした際に変わってしまう恐れがあるため、利用者が定めた文字列で明示的に設定しておくほうが良いと思われる。 ★ACLの設定方法/ターゲット側 (Solaris) 正規のイニシエーターiqn名は文字列が長すぎて扱いにくいため、ローカルイニシエーター名を設定する # iscsitadm create initiator --iqn iqn.1998-01.com.vmware hydro-12345678 hydro-vm # iscsitadm create initiator --iqn iqn.1998-01.com.vmware black-12345678 black-vm ローカルイニシエーター名の設定結果を確認する # iscsitadm list initiator -v Initiator black-vm iSCSI Name iqn.1998-01.com.vmware black-12345678 CHAP Name Not set CHAP Secret Not set Initiator hydro-vm iSCSI Name iqn.1998-01.com.vmware hydro-12345678 CHAP Name Not set CHAP Secret Not set ボリューム毎に接続相手を設定する # iscsitadm modify target --acl hydro-vm tank/vmvol # iscsitadm modify target --acl black-vm tank/vmvol ACLの設定結果を確認する # iscsitadm list target -v tank/vmvol Target tank/vmvol iSCSI Name iqn.1986-03.com.sun 01 a1b2c3d4-e5f6-g7h8-i9j0-1234567890ab Alias tank/vmvol Connections 0 ACL list Initiator black-vm Initiator hydro-vm TPGT list LUN information LUN 0 GUID xxxxxxxxxxxxxxxxxxxxxxxx VID SUN PID SOLARIS Type disk Size 500G Backing store /dev/zvol/rdsk/tank/vmvol Status online 注意点認証設定は、イニシエーター/ターゲットの接続が確立する前に実施すること。確立後に設定すると、接続が切れる(イニシエーター側サーバがシャットダウンする等)までは認証は機能しない。
https://w.atwiki.jp/api_programming/pages/37.html
下位ページ Content 認証リクエスト OAuth2.0 の概要 WebサーバアプリケーションのOauth 2.0認証 Using OAuth 2.0 for Web Server Applications 概要 認証プロトコルについて OAuth 2.0 による認証 いろんな言語のライブラリ web application credentialsを作る web application credentials を得るステップ Preparing to start the OAuth 2.0 flowGoogle's OAuth 2.0 サーバにリダイレクト OAuth 2.0 serverのレスポンスを扱う Google APIsを呼び出す サンプル完全版Incremental authorization Offline accessトークンのリクエストjava? リダイレクトのURLから、codeを処理する authorization code と access token の交換 認証リクエスト Google APIにリクエストを送るには、アプリケーションの「identify」が必要で、その方法は2つある。 OAuth 2.0 token (which also authorizes the request) API key どちらをつかうのか、は以下で決まる。 プライベートデータを使うときは、OAuth 2.0 token でなければならない。アプリケーションには API key も配布されるが必須でない。 パブリックデータを使うときは the API key でも OAuth 2.0 token 使いやすい方で良い, or both—whatever option is most convenient for you. OAuth2.0 の概要 https //developers.google.com/identity/protocols/OAuth2?csw=1 WebサーバアプリケーションのOauth 2.0認証 Using OAuth 2.0 for Web Server Applications Google API の認証 Google Identity Platform https //developers.google.com/identity/protocols/OAuth2WebServer Using OAuth 2.0 for Web Server Applications Google APIsを使うために、Google API Client Libraries or Google OAuth 2.0 endpoints が使える。 OAuth 2.0 で、ユーザは、ユーザ名やパスワードをプログラムに渡すことなく、Google アプリケーションのデータが使える。 概要 まず、APIコンソールでプロジェクトの「web application credentials」をつくる。アプリケーションがユーザーデータにアクセスする必要がある場合は、ユーザーはGoogle's OAuth 2.0 serverにリダイレクトされる。OAuth 2.0 server はユーザ承認をして、アプリケーションからのデータアクセスに必要な「consent」を得る。 OAuth 2.0 serverはユーザーをアプリケーションにリダイレクトする(戻す)。このとき、承認コードを返す。アプリケーションで承認コードをアクセストークンに交換する。 アプリケーションは承認コードを使って、Google API にアクセスする。 When you use a Google API Client Library to handle your application's OAuth 2.0 flow, the client library keeps track of when a stored access token can be used and when the application must re-acquire consent, generates correct redirect URLs, and helps to implement redirect handlers that exchange authorization codes for access tokens. An application that carries out the OAuth 2.0 flow without using a client library must correctly complete the same steps. Client libraries The language-specific examples on this page make use of the Google API Client Libraries, which make API authorization with OAuth 2.0 simpler. To run the example code, you must first install the client library for your language. 認証プロトコルについて OAuth 2.0しかないが、Google Sign-In が使えるアプリケーションなら、違う「扱い方」をすることが可能 OAuth 2.0 による認証 Requests to the Google Sheets API for non-public user data must be authorized by an authenticated user. The details of the authorization process, or "flow," for OAuth 2.0 vary somewhat depending on what kind of application you're writing. The following general process applies to all application types アプリケーションを作成したら、Google API Console に使用登録をする。これに関する細かな情報は後述。 (Sheets API を使うのであれば)Google Sheets API を Google API Console でアクティベートする。(使用する API がリストになければ、このステップは飛ばす) アプリケーションがユーザーデータを必要とするのであれば、Google に アクセススコープを要求する。 Google はユーザーに確認画面を表示し、アプリケーションを認証するか尋ねる。 ユーザが認証したら、Google がアプリケーションにアクセストークンを発行する。 アプリケーションがユーザーデータ(プライベートデータ)を要求する場合は、アクセストークンをつけて要求する。 Google はリクエストとトークンが有効と判断したら、要求されたデータを返す 以上が基本の流れで、ところどころ追加ステップが必要になる。例えば、トークンの有効期限が切れた場合のリフレッシュ作業など。 いろんな言語のライブラリ 省略 web application credentialsを作る All web applications that use OAuth 2.0 must have credentials that identify the application to the OAuth 2.0 server. Applications that have these credentials can access the APIs that you enabled for your project. web application credentials を得るステップ APIコンソールの認証情報ページへ。 (まだ作っていなければ)「認証情報を作成」をクリックして、OAuth クライアント ID を選択する。 次に、クライアントIDとクライアントSecretを探す。 リダイレクトURIも編集。リダイレクトURIはエンドポイントで、レスポンスに乗ってくる情報を処理する。ローカルマシンで試す場合は、http //localhost 8080みたいなのも可。 client_secrets.jsonファイルをダウンロードしてセキュリティ性を保って保管する(ほうがいい) Important Do not store the client_secrets.json file in a publicly-accessible location, and if you share the source code to your application—for example, on GitHub—store the client_secrets.json file outside of your source tree to avoid inadvertently sharing your client credentials. Preparing to start the OAuth 2.0 flow If you are using a Google API client library to handle the OAuth 2.0 flow, configure the client object, which you will use to make OAuth 2.0 requests. If you are handling the flow by directly accessing the OAuth 2.0 endpoints, just take note of the client ID that you created in the previous step and the scopes you need to request. To configure the client object HTTP/REST Take note of the following values Your app's client ID and client secret, which you created in Creating web application credentials. The scopes that your app needs to request. See the documentation for the APIs your app uses for the required scopes. Google's OAuth 2.0 サーバにリダイレクト HTTP/REST https //accounts.google.com/o/oauth2/v2/auth HTTP はだめ。HTTPSで。 https //accounts.google.com/o/oauth2/v2/auth? scope=email%20profile state=security_token%3D138r5719ru3e1%26url%3Dhttps //oa2cb.example.com/myHome redirect_uri=https%3A%2F%2Foauth2.example.com%2Fcode , response_type=code client_id=812741506391.apps.googleusercontent.com The set of query string parameters supported by the Google Authorization Server for web server applications are Parameter Values Description response_type code Determines whether the Google OAuth 2.0 endpoint returns an authorization code. Web server applications should use code. client_id クライアントID リクエストを出したクライアントの特定 required redirect_uri コンソールで登録したリダイレクトURIの一つ 登録されたURIとピッタリ合わないとだめ。(http / https も scope アプリケーションにリクエストするパーミッション(スペース区切り) 使うスコープは承認画面でユーザーに公開される。要求されたパーミッション数と、ユーザーの同意を得る可能性との間には逆の可能性があります。使えるスコープの種類は、APIs Explorerで確認のこと。It is generally a best practice to request scopes incrementally, at the time access is required, rather than up front. 例えば、For example, an app that wants to support purchases should not request Google Wallet access until the user presses the “buy” button; see Incremental authorization. state Any string Provides any state that might be useful to your application upon receipt of the response. The Google Authorization Server roundtrips this parameter, so your application receives the same value it sent. To mitigate against cross-site request forgery (CSRF), it is strongly recommended to include an anti-forgery token in the state, and confirm it in the response. See OpenID Connect for an example of how to do this. access_type online / offline Indicates whether your application needs to access a Google API when the user is not present at the browser. This parameter defaults to online. If your application needs to refresh access tokens when the user is not present at the browser, then use offline. This will result in your application obtaining a refresh token the first time your application exchanges an authorization code for a user. prompt Space-delimited, case-sensitive list of prompts to present the user. If you don't specify this parameter, the user will be prompted only the first time your app requests access. 可能なあたいとして、"none" 画面を出さないMust not be specified with other values. consentPrompt the user for consent select_accountPrompt the user to select an account login_hint email address or sub identifier When your application knows which user it is trying to authenticate, it can provide this parameter as a hint to the Authentication Server. Passing this hint will either pre-fill the email box on the sign-in form or select the proper multi-login session, thereby simplifying the login flow. include_granted_scopes true / false If this is provided with the value true, and the authorization request is granted, the authorization will include any previous authorizations granted to this user/application combination for other scopes; see Incremental Authorization. After you create the request URL, redirect the user to it. Google's OAuth 2.0 server will authenticate the user and obtain consent from the user for your application to access the requested scopes. The response will be sent back to your application using the redirect URL you specified. OAuth 2.0 serverのレスポンスを扱う ユーザがアクセス要求を承認すると、認証コードが送られてくる。 承認しなければ、レスポンスにはエラーメッセージが含まれてくる。 All responses are returned to the web server on the query string, as shown below エラー https //oauth2.example.com/auth?error=access_denied 承認 https //oauth2.example.com/auth?code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7 Important If your response endpoint renders an HTML page, any resources on that page will be able to see the authorization code in the URL. Scripts can read the URL directly, and all resources may be sent the URL in the Referer HTTP header. Carefully consider if you want to send authorization credentials to all resources on that page (especially third-party scripts such as social plugins and analytics). To avoid this issue, we recommend that the server first handle the request, then redirect to another URL that doesn't include the response parameters. 認証コードを受け取ったら、アクセストークンと交換 ここにアクセス https //www.googleapis.com/oauth2/v4/token 使用するパラメータ Field Description code The authorization code returned from the initial request. client_id The client ID obtained from the API Console. client_secret The client secret obtained from the API Console. redirect_uri One of the redirect URIs listed for this project in the API Console. grant_type As defined in the OAuth 2.0 specification, this field must contain a value of authorization_code. リクエスト例 POST /oauth2/v4/token HTTP/1.1 Host www.googleapis.com Content-Type application/x-www-form-urlencoded code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7 client_id=8819981768.apps.googleusercontent.com client_secret={client_secret} redirect_uri=https //oauth2.example.com/code grant_type=authorization_code リクエストが通ると以下のレスポンスが戻る Field Description access_token Google APIにアクセスするためのトークン refresh_token 新しいアクセストークンを得るためのトークン。ユーザが承認を取り消すまで有効。このフィールドは access_type=offline が認証コードリクエストに含まれていれば、only present expires_in The remaining lifetime of the access token. token_type Identifies the type of token returned. At this time, this field will always have the value Bearer. レスポンスはJSONで帰ってくる { "access_token" "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in" 3920, "token_type" "Bearer" } Note Other fields may be included in the response, and your application should not treat this as an error. The set shown above is the minimum set. Google APIsを呼び出す HTTP/REST access tokenを使って、APIを呼び出す。access token は (サーバログに残ってしまうので良くないが)"access_token" としてパラメータに含めるか、 (推奨は)HTTPヘッダの Authorization Bearer に含める。 You can try out all the Google APIs and view their scopes at the OAuth 2.0 Playground. 例 A call to the drive.files endpoint (the Drive API) using the access_token query string parameter might look like the following, though you'll need to specify your own access token GET https //www.googleapis.com/drive/v2/files?access_token=1/fFBGRNJru1FQd44AzqT3Zg Authorization Bearer HTTP header を使って同じことをすると GET /drive/v2/files HTTP/1.1 Authorization Bearer 1/fFBGRNJru1FQd44AzqT3Zg Host googleapis.com You can try out with the curl command-line application. Here's an example using the HTTP header option (preferred) curl -H "Authorization Bearer 1/fFBGRNJru1FQd44AzqT3Zg" https //www.googleapis.com/drive/v2/files Or, alternatively, the query string parameter option curl https //www.googleapis.com/drive/v2/files?access_token=1/fFBGRNJru1FQd44AzqT3Zg Google/Sheets API サンプル完全版 The following example prints a JSON-formatted list of files in a user's Google Drive after the user authenticates and gives consent for the application to access the user's Drive files. HTTP/REST This example in Python uses the Flask framework and the Requests library to demonstrate the OAuth 2.0 web flow. Note that using the Python client library is easier and is the recommended way to implement this flow. import json import flask import requests app = flask.Flask(__name__) CLIENT_ID = '123456789.apps.googleusercontent.com' CLIENT_SECRET = 'abc123' # Read from a file or environmental variable in a real app SCOPE = 'https //www.googleapis.com/auth/drive.metadata.readonly' REDIRECT_URI = 'http //example.com/oauth2callback' @app.route('/') def index() if 'credentials' not in flask.session return flask.redirect(flask.url_for('oauth2callback')) credentials = json.loads(flask.session['credentials']) if credentials['expires_in'] = 0 return flask.redirect(flask.url_for('oauth2callback')) else headers = {'Authorization' 'Bearer {}'.format(credentials['access_token'])} req_uri = 'https //www.googleapis.com/drive/v2/files' r = requests.get(req_uri, headers=headers) return r.text @app.route('/oauth2callback') def oauth2callback() if 'code' not in flask.request.args auth_uri = ('https //accounts.google.com/o/oauth2/v2/auth?response_type=code' ' client_id={} redirect_uri={} scope={}').format(CLIENT_ID, REDIRECT_URI, SCOPE) return flask.redirect(auth_uri) else auth_code = flask.request.args.get('code') data = {'code' auth_code, 'client_id' CLIENT_ID, 'client_secret' CLIENT_SECRET, 'redirect_uri' REDIRECT_URI, 'grant_type' 'authorization_code'} r = requests.post('https //www.googleapis.com/oauth2/v4/token', data=data) flask.session['credentials'] = r.text return flask.redirect(flask.url_for('index')) if __name__ == '__main__' import uuid app.secret_key = str(uuid.uuid4()) app.debug = False app.run() Incremental authorization In the OAuth 2.0 protocol, your app requests authorization to access resources which are identified by scopes, and assuming the user is authenticated and approves, your app receives short-lived access tokens which let it access those resources, and (optionally) refresh tokens to allow long-term access. It is considered a best user-experience practice to request authorization for resources at the time you need them. For example, an app that lets people sample music tracks and create mixes might need very few resources at sign-in time, perhaps nothing more than the name of the person signing in. However, saving a completed mix would require access to their Google Drive. Most people would find it natural if they only were asked for access to their Google Drive at the time the app actually needed it. In this case, at sign-in time the app might request the profile scope to perform basic sign-in, and then later request the https //www.googleapis.com/auth/drive.file scope at the time of the first request to save a mix. Using the procedures described in Using OpenID Connect and Using OAuth 2.0 to Access Google APIs would normally result in your app having to manage two different access tokens. To avoid this complexity, you can include previously granted scopes in your authorization requests. For example HTTP/REST GET https //accounts.google.com/o/oauth2/v2/auth? scope=https //www.googleapis.com/auth/drive.file state=security_token%3D138r5719ru3e1%26url%3Dhttps //oa2cb.example.com/myHome redirect_uri=https%3A%2F%2Fmyapp.example.com%2Fcallback response_type=code client_id=8127352506391.apps.googleusercontent.com prompt=consent include_granted_scopes=true Let's call the resulting authorization the "combined authorization"; the following apply You can use the access tokens you get to access the resources corresponding to any of the scopes that are rolled into the combined authorization. When you use the refresh token for a combined authorization, the new access tokens represent the combined authorization and can be used for any of its scopes. The combined authorization includes any previously granted authorizations even if they were requested from different clients. For example, if you requested the profile scope from a desktop app, and then issued the request in the example URI above for the same user from a mobile app, and it was granted, the combined authorization would include both scopes. When you revoke a token which represents a combined authorization, all of the authorizations are revoked simultaneously; this means that if you retain a token for one of the previous authorizations, it will stop working. When you make an authorization request with granted scopes included, the Google authorization server rolls the authorization request together with all the previous authorizations granted to the requesting user from the requesting app. Offline access ユーザが使っていない場合でもAPIにアクセスする必要がある場合があるかも。たとえば、バックアップの場合や「月曜8時にBlobをポスト」のような場合。 このタイプのアクセスを「offline」と呼び、ウェブサーバアプリはオフラインリクエストができる。 これに対し、通常のアクセスはonlineである。 HTTP/REST If your application needs offline access to a Google API, then the request for an authorization code should include the access_type parameter, where the value of that parameter is offline. For example https //accounts.google.com/o/oauth2/v2/auth? scope=email%20profile state=security_token%3D138r5719ru3e1%26url%3Dhttps //oa2cb.example.com/myHome redirect_uri=https%3A%2F%2Foauth2.example.com%2Fcode response_type=code client_id=812741506391.apps.googleusercontent.com access_type=offline The first time a given user's browser is sent to this URL, they see a consent page. If they grant access, then the response includes an authorization code which may be redeemed for an access token and a refresh token. An example of an authorization code exchange is shown below POST /oauth2/v4/token HTTP/1.1 Host www.googleapis.com Content-Type application/x-www-form-urlencoded code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7 client_id=8819981768.apps.googleusercontent.com client_secret={client_secret} redirect_uri=https //oauth2.example.com/code grant_type=authorization_code If this is the first time the application has exchanged an authorization code for a user, then the response includes an access token and a refresh token, as shown below { "access_token" "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in" 3920, "token_type" "Bearer", "refresh_token" "1/xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI" } Important When your application receives a refresh token, it is important to store that refresh token for future use. If your application loses the refresh token, it will have to re-prompt the user for consent before obtaining another refresh token. If you need to re-prompt the user for consent, include the prompt parameter in the authorization code request, and set the value to consent. After your application receives the refresh token, it can obtain new access tokens at any time. See the section on refresh tokens for more information. The next time your application requests an authorization code for that user, the user will not be asked to grant consent (assuming they previously granted access, and you are asking for the same scopes). As expected, the response includes an authorization code which may be redeemed. However, unlike the first time an authorization code is exchanged for a given user, a refresh token will not be returned from the authorization code exchange. The following is an example of such a response { "access_token" "1/fFAGRNJru1FQd77BzhT3Zg", "expires_in" 3920, "token_type" "Bearer", } Using a refresh token As indicated in the previous section, a refresh token is obtained in offline scenarios during the first authorization code exchange. In these cases, your application may obtain a new access token by sending a refresh token to the Google OAuth 2.0 Authorization server. To obtain a new access token this way, your application sends an HTTPS POST request to https //www.googleapis.com/oauth2/v4/token. The request must include the following parameters FieldDescription refresh_tokenThe refresh token returned from the authorization code exchange. client_idThe client ID obtained from the API Console. client_secretThe client secret obtained from the API Console. grant_typeAs defined in the OAuth 2.0 specification, this field must contain a value of refresh_token. Such a request will look similar to the following POST /oauth2/v4/token HTTP/1.1 Host www.googleapis.com Content-Type application/x-www-form-urlencoded client_id=8819981768.apps.googleusercontent.com client_secret={client_secret} refresh_token=1/6BMfW9j53gdGImsiyUH5kU5RsR4zwI9lUVX-tqf8JXQ grant_type=refresh_token As long as the user has not revoked the access granted to your application, the response includes a new access token. A response from such a request is shown below { "access_token" "1/fFBGRNJru1FQd44AzqT3Zg", "expires_in" 3920, "token_type" "Bearer", } Note that there are limits on the number of refresh tokens that will be issued; one limit per client/user combination, and another per user across all clients. You should save refresh tokens in long-term storage and continue to use them as long as they remain valid. If your application requests too many refresh tokens, it may run into these limits, in which case older refresh tokens will stop working. Revoking a token In some cases a user may wish to revoke access given to an application. A user can revoke access by visiting Account Settings. It is also possible for an application to programmatically revoke the access given to it. Programmatic revocation is important in instances where a user unsubscribes or removes an application. In other words, part of the removal process can include an API request to ensure the permissions granted to the application are removed. PHPPYTHONRUBYHTTP/REST To programmatically revoke a token, your application makes a request to https //accounts.google.com/o/oauth2/revoke and includes the token as a parameter curl https //accounts.google.com/o/oauth2/revoke?token={token} The token can be an access token or a refresh token. If the token is an access token and it has a corresponding refresh token, the refresh token will also be revoked. If the revocation is successfully processed, then the status code of the response is 200. For error conditions, a status code 400 is returned along with an error code. Note Following a successful revocation response, it might take some time before the revocation has full effect. Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the Apache 2.0 License. For details, see our Site Policies. Java is a registered trademark of Oracle and/or its affiliates. Using OAuth 2.0 with the Google API Client Library for Java {{ Authorization Code Flow https //code.google.com/p/google-api-java-client/wiki/OAuth2#Authorization_Code_Flow 実装にはGoogleAuthorizationCodeFlowを用いる。 まず、API使用が登録済みであること。client id, client secret等々をもらっておく Authorization codeをもらう持っていなければ、認証URLへ。 ユーザIDをもとに、AuthorizationCodeFlow.loadCredential(String userID)を呼び出す既に証明書を持っているかを確認。持っていれば、終了。 認証されると、"code"と一緒にリダイレクトされる。 "code"を使って access token を要求する AuthorizationCodeFlow.newTokenRequest(String)でアクセストークン(access token)を要求。AuthorizationCodeFlow.createAndStoreCredential(TokenResponse, String) http //javadoc.google-oauth-java-client.googlecode.com/hg/1.18.0-rc/com/google/api/client/auth/oauth2/AuthorizationCodeFlow.html#createAndStoreCredential(com.google.api.client.auth.oauth2.TokenResponse,%20java.lang.String)]] で、証明書を取得し保管。 レスポンスからaccess tokenを取得 ※Lower-Levelの実装方法もある https //code.google.com/p/google-api-java-client/wiki/OAuth2#Authorization_Code_Flow }} トークンのリクエスト リクエスト先 https //accounts.google.com/o/oauth2/authSSLを使用すること。httpはダメ リクエストに加えるのは Parameter Values 必須 Description response_type "code" ◯ Webサーバアプリケーションでは code で決め打ち client_id client_id ◯ API使用の登録で貰ったID.忘れていたらconsoleで確認 redirect_uri One of the redirect_uri ◯? リダイレクト先は複数登録されているので、どこにリダイレクトするのかここで書いておく。 scope Space-delimited set of permissions that the application requests. ◯ APIでどこまでユーザーのデータにアクセスするか(できるか)。複数ある場合はスペース区切り。どのような値を入れるかは、各APIのリファレンスページ(the APIs Explorer)参照。極力「最小」にしておく。必要なら後で追加認証をする感じで。 state Any string レスポンスを受け取る際に使える「状態」。cross-site request forgery (CSRF)の対策?なので、強く推奨。レスポンスを受け取って、これを確認すれば、変なとこで使われていないか、確認できる。 access_type offline or online ユーザがブラウザを使ってない時でもアプリケーションがアクセスするかどうか。自動的にトークンのリフレッシュが必要ならoffline。 approval_prompt force or auto optional デフォルトでauto 接続の度にプロンプトを出して訊くかどうか? login_hint email address or sub identifier optional どのユーザが認証を行おうとしているかアプリケーション側でわかっている場合、(例えばそのユーザのemailアドレスを)パラメータとして渡すことができる。 include_granted_scopes true or false optional If this is provided with the value true, and the authorization request is granted, the authorization will include any previous authorizations granted to this user/application combination for other scopes; see Incremental Authorization. リクエストのスペース等々はエスケープする。 java.net.URLEncoder とか サンプル(改行は見やすくするため) https //accounts.google.com/o/oauth2/auth? scope=email%20profile state=security_token%3D138r5719ru3e1%26url%3Dhttps //oa2cb.example.com/myHome redirect_uri=https%3A%2F%2Foauth2-login-demo.appspot.com%2Fcode , response_type=code client_id=812741506391.apps.googleusercontent.com approval_prompt=force リクエストが正しく通れば、以下が返ってくる access tokens refresh tokens authorization codes. java? AuthorizationCodeFlow.newAuthorizationUrl()が使える? リダイレクトのURLから、codeを処理する Handling the response The response will be sent to the redirect_uri as specified in the request URL. If the user approves the access request, then the response contains an authorization code and the state parameter (if included in the request). If the user does not approve the request, the response contains an error message. All responses are returned to the web server on the query string, as shown below 認証失敗 https //oauth2-login-demo.appspot.com/code? bold(){error=access_denied} state=security_token%3D138r5719ru3e1%26url%3Dhttps //oa2cb.example.com/myHome 認証成功 https //oauth2-login-demo.appspot.com/code?state=security_token%3D138r5719ru3e1%26url%3Dhttps //oa2cb.example.com/myHome bold(){code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7} リダイレクト先が通常のHTMLページの場合は、そのままURLが見える、つまりcodeが見えてしまう。 Scripts can read the URL directly, and all resources may be sent the URL in the Referer HTTP header. Carefully consider if you want to send authorization credentials to all resources on that page (especially third-party scripts such as social plugins and analytics). この問題を避けるために、サーバでリクエストを扱って、それからパラメータを含まない形で別のURLにリダイレクトするべき。 authorization code と access token の交換 After the web server receives the authorization code, it may exchange the authorization code for an access token and a refresh token. This request is an HTTPS POST to the URL https //www.googleapis.com/oauth2/v3/token, and includes the following parameters Field Description code authorization code client_id The client ID client_secret The client secret obtained from the Developers Console redirect_uri One of the redirect URIs grant_type ここでは "authorization_code" の決め打ち レスポンス例(成功時) { "access_token" "ya29.vAHSwBFxEzkYKAeqk461biUJ9dqSD8KglnarHgBaR7q7Ih_4TlT71KEh07QBR6_tfLVv", "token_type" "Bearer", "expires_in" 3600}
https://w.atwiki.jp/clickvip/pages/326.html
このページは編集中です。正しくない内容が含まれますのでご注意ください。 他動認証とは 認証できないクリッカーのためにその認証を手伝うシステム。 他動認証とは、おやすみ中・おでかけ中のクリッカーの代わりに、前線にいるクリッカーが遠隔から認証するシステムです。前者が「認証してもらう人」(砲台)、後者は「認証する人」(認証人)です。 わかりやすい解説FLASHがあります。ぜひ ここをクリック ! 他人のかわりに「 認証する 」。とても簡単です。 「斧(ACS)」で他人に「認証してもらう」 (※ 説明 ) 「ほのか(炎火山)」で他人に「認証してもらう」 (※: 説明 ) 認証の基本 「 認証支援ツール 」が使いやすくておすすめです。 認証文字の法則:FAQの「 認証の文字が見にくい 」を知っておくと認証の正答率アップ! 認証支援ツールで認証(おすすめ) 他人の認証の手助けをする専用のツールです。それぞれ、説明をよく読んで使用してください。 ほのか砲台用ツール「 やまびこ 」!(Windows,Mac,Linux) 斧砲台用ツール「 小町(こまち) 」!(何でも) の2つが現在日本の主力支援ツールです。どちらも使い方は簡単! それ以外に、こちらのツールもおすすめです。ほのか砲台用「 疾風 」(Windows) ほのか砲台用「 神無(かんな) 」(Windows,Mac,Linux。FireFoxほのかサイドバー付属) ほのか砲台用「 ClickJapanWidget 」(Mac用お手軽認証ツール。) その他の認証方法(ケース・バイ・ケースで!) ほのかで他動 「ほのか」に付属のツールバーで認証支援ができます。 ほのかで他動の説明はここをクリック! FireFoxのメニューから、 「表示」→「サイドバー」→「ほのかピア他動認証サイドバー」 で他動認証サイドバーが開きます。 サイドバーの幅を広くして2列にすると認証作業がやりやすくなります。 #ref error :画像を取得できませんでした。しばらく時間を置いてから再度お試しください。 ※クリックで拡大 ブラウザで他動 ツールを使わなくても、ブラウザで認証も出来ます。 ブラウザで他動はここをクリック! いくつかページがありますが、場所によって登録している人が違います。見比べてみて、手薄なところをよろしくお願いします。 認証ページ:他動認証ホスト一覧 ※自動更新サーバー taneさんの管理するサーバー。 認証ページ:フェアリーさくらたん ※自動更新サーバー 妖精さんの管理するサーバー。 認証ページ:登録所戦場 ※自動更新サーバー 上のページへ行き、「他動認証する(自動登録)」を選びます。 他動認証する(手動登録)は、過去の遺物です。「自動登録」と「手動登録」の違いに注意!! 認証ページ:スキンのある他動認証 ※手動サーバー 基本みんなスキンあり。スキンを見て楽しみながら認証できます。 ※ブラウザで他動するときの注意 認証時に「不正なリクエストのため認証を拒絶しました」と出ることがあります。他の人が先に認証しただけなので気にしないでOK。 特にIEやSleipnirの方で、大量のスクリプトエラーが出ることがあります。sleipnirの場合は「セキュリティ」→「不要なダイアログを抑制」にチェックを入れれば出なくなるかもしれません。Firefoxなどのブラウザを使用すると大丈夫な場合があります。 他動ツール の使用をおすすめします。 携帯で他動 携帯用認証ページで携帯からも認証できます。 http //clickclickclick.dyndns.org/p2p/mobile.cgi http //www.click3.uni.cc/FireVolcano/_attest.cgi?page=0 size=3 http //www.happy2-island.com/cgi/acsupporter/account.cgi 砲台設定のやりかた 「斧」で認証してもらう人へ 斧の場合、無人モード設定が必要になります。設定方法は こちら へどうぞ。 参考:斧(ACS)のページで他動認証待ちの時間を変える方法やダイアログ出なくする方法が書いてあります。 「ほのか」で認証してもらう人へ ほのかの場合、初期設定のままで他動認証されます。 更に簡単な設定(ポート開け&公衆開示)を追加することでネットワーク負荷を軽減したり、他のほのかの手助けをすることができます。 ほのかの他動認証追加設定方法は こちら へどうぞ。 他動認証窓用のスキンはこちら その他の情報 日本のライバルである台湾・ハンガリーとも他動認証を取り入れています。認証人のことを台湾では「打字兵」、ハンガリーでは「shooter」と呼んでいるようです。 疾風の認証ランキング上位の認証スピードを動画。( youtube , ニコ動 )凄まじい速さです。 ここの情報は最新情報に追いついていない場合があります。最新情報を取り入れたい場合は、 ここ から「他動認証スレ」を探してください。
https://w.atwiki.jp/sanosoft/pages/48.html
htaccessによるDigest認証 WEBページにアクセス制限設ける場合に、一般的にBasic認証が使われていますが、Basic認証だとパスワードが平文で送信されるので、セキュリティ的に脆弱となります。 その点、Digest認証にすると、ユーザ名とパスワードをMD5でハッシュ(ダイジェスト)化して送信するため、より安全となります。 1. Apacheの設定 Digest認証を行う場合には、Apacheで「auth_digest_module」を有効にする必要があります。 LoadModule auth_digest_module modules/mod_auth_digest.so 2. パスワードファイルの作成 パスワードファイルを作成するには、以下のコマンドを実行します。 # htdigest -c (パスワードファイル名) (レルム) (ユーザ名) ※「-c」オプションは、新規でファイルを作成する場合に指定します。 なお、コマンドを実行するとパスワードを聞かれますので、(ユーザ名)に対応するパスワードを入力して下さい。 【例】 # htdigest -c /var/_private/.htdigest "This site is a protected site." web_user 3. .htaccessファイルの作成 AuthType Digest AuthName "This site is a protected site." AuthUserFile /var/_private/.htdigest Require valid-user ※「AuthName」はパスワードファイルの作成時に指定した「レルム」と同じ文字列を入力します。 4. httpd.confに記述する場合 httpd.confに記述する場合には Directory セクションではなく、必ず Location セクションに記述します。 Location "/" AuthType Digest AuthName "This site is a protected site." AuthUserFile /var/_private/.htdigest Require valid-user /Location 5. 特定のファイルのみ認証を除外する方法 (1) .htaccessの場合 該当のファイル名をFileMatchで除外します。 【例】_health.htmlのみを除外 FilesMatch "^(_health\.html)$" Satisfy any Require all granted /FilesMatch (2) httpd.confもしくはVirtualHostに記述する場合 Location で指定します。 【例】/health.htmlのみを除外 VirtualHost * 80 Location /health.html Satisfy any Require all granted /Location /VirtualHost 6. 特定のディレクトリのみ認証を除外する方法 (1) .htaccessに記述する場合 除外したいフォルダの.htaccessに以下の記述をします。 Satisfy any Require all granted (2) httpd.confもしくはVirtualHostに記述する場合 Directory "/var/www/html/except" satisfy any Require all granted /Directory 7. 特定のファイルのみ認証を掛ける方法 (1) .htaccessの場合 該当のファイル名をFileMatchで認証を掛けます。 【例】members.htmlのみを除外 FilesMatch "^(members\.html)$" AuthType Digest AuthName "This site is a protected site." AuthUserFile /var/_private/.htdigest Require valid-user /FilesMatch (2) httpd.confもしくはVirtualHostに記述する場合 Location で指定します。 【例】/members.htmlのみを掛ける VirtualHost * 80 Location /members.html AuthType Digest AuthName "This site is a protected site." AuthUserFile /var/_private/.htdigest Require valid-user /Location /VirtualHost 8. サイト全体のDigest認証とは別に特定のサブディレクトリに異なるDigest認証を設定する 例えば、サイト全体にDigest認証がかかっている状態で、その配下の「/pretest/」のみ別の認証を設定したい場合です。 下記の例では、リクエストURIが「/pretest/」の場合とその他の場合で分岐しています。 なお、「/pretest/」のスラッシュをそのまま記載すると500エラーになるので、「\x2F」にします。 If "%{REQUEST_URI} =~ /^\x2Fpretest\x2F.*/" AuthType Digest AuthName "This site is a protected site." AuthUserFile /var/_private/.htdigest_pretest Require valid-user /If Else AuthType Digest AuthName "This site is a protected site." AuthUserFile /var/_private/.htdigest Require valid-user /Else 9. 特定のIPのみ認証を除外する場合 内部IPの場合には認証を外す。 Directory "/var/www/html" RequireAny AuthType Digest AuthName "This site is a protected site." AuthUserFile /var/_private/.htdigest Require valid-user Require ip 10. /RequireAny /Directory 10. Digest認証とIPアクセス制限を同時に掛ける場合 RequireAll AuthType Digest AuthName "This site is a protected site." AuthUserFile /var/_private/.htdigest Require valid-user RequireAny Require ip xxx.xxx.xxx.xxx /RequireAny /RequireAll 11. WebRelease2に認証を付ける場合 # vi /etc/httpd/conf/httpd.conf IfModule mod_proxy.c Proxy * AuthType Digest AuthName "This site is a protected site." AuthUserFile /var/_private/.htdigest_wr2 Require valid-user /Proxy ProxyPass /WebRelease2 http //127.0.0.1 50002/WebRelease2 ProxyPassReverse /WebRelease2 http //127.0.0.1 50002/WebRelease2 ProxyTimeout 1800 /IfModule
https://w.atwiki.jp/ma-100140/pages/16.html
現在つくっているシステムの認証にADを利用しようと思い立ち、PHPでLDAPを利用して実装しました。 PHPの設定変更(win版:テスト環境、自分のPC) php.iniのexstensionのコメントをはず ssleay32.dllとlibeay32.dllがapacheから参照できることが前提 win版はすんなりと設定できましたVersion 5.2.6 PHPの設定変更(linux版:本番環境、サーバー) 本番環境はソースからコンパイルしているため、PHPを再コンパイルする必要がありました。 流れとしては Berkeley DB を導入 OpenLDAP 2.4.11-Releaseの導入 phpの再コンパイル Berkeley DB の導入 $ tar zxvf db-4.7.25.NC.tar.gz $ cd db-4.7.25/build_unix/ $ ../dist/configure $ make $ make instrall $ chown -R root wheel /usr/local/BerkeleyDB.4.7 OpenLDAP 2.4.16の導入 openldap-stable-20080813.tgzをダウンロード $./configure 途中略 checking for db.h... yes checking for Berkeley DB major version... 4 checking for Berkeley DB minor version... 1 checking for Berkeley DB link (-ldb-4)... no checking for Berkeley DB link (-ldb4)... no checking for Berkeley DB link (-ldb)... yes checking for Berkeley DB version match... yes checking for Berkeley DB thread support... yes checking Berkeley DB version for BDB/HDB backends... no configure error BDB/HDB BerkeleyDB version incompatible Berkeley DB のバージョンが違う? 実は最初は何も考えずにOpenLDAPから作業を開始しました。 そうしたら、もともと4.1がインストールされていたみたいです。 そこで、最新のBerkeley DB4.7をインストールしましたが、うまく行かない。 色々ググってみると、バージョンは4.2がいいみたい。 OpenLDAPとBerkeley DBのバージョンの組み合わせ OpenLDAP Berkeley DB 4.1 4.2 4.6 4.7 2.3.43 incompatible ○ × × 2.4.11 incompatible ○ × × 2.4.16 incompatible × × × 最終的な手順 Berkeley DB4.2の導入 $cd db-4.2.52.NC $cd build_unix $../dist/configure $make $make install $ chown -R root wheel /usr/local/BerkeleyDB.4.2 OpenLDAP 2.4.11の導入 $ vi /etc/ld.so.conf でBerkeley DB4.2のライブラリーを追加 $ ldconfig で変更を適用 $ cd OpenLDAP2.4.11 $ CPPFLAGS=-I/usr/local/BerkeleyDB.4.2/include LDFLAGS=-L/usr/local/BerkeleyDB.4.2/lib ./configure $ make $ make test $ make install でやっと導入できました。 PHPの再コンパイル ./configure --with-mysql=/usr/local/mysql --with-apxs=/www/bin/apxs \ --with-gd --with-jpeg-dir=/usr/local/lib --with-zlib-dir=/usr/local/lib \ --enable-mbstring \ --with-ldap=/usr/local phpでのテスト結果 認証プログラム
https://w.atwiki.jp/0-0-3-8/pages/18.html
動作確認 DB名 sampleDB テーブル名 login スキーマ sample user_id(character varying[10]) password(character varying[10]) name1 0038 name2 syouki name3 ikuoys name4 arutarufu 引き続きSampleディレクトリを使用します。 上記のデータベースを作成します。 PostgreSQLを起動するので先ほど作成した「サービスの起動.exe」をダブルクリックします。 先程作成した 「pgAdmin3.exe」 のショートカットをダブルクリックします。 「PostgreSQL Database Server 8.2」 をダブルクリックします。 DB を構築するので「データベース」 を右クリックし、「新しいデータベース」 を選択し、名前に「sampleDB」を入力して「OK」をクリックします。 テーブルを作成するので作成した DB の階層にある 「スキーマ」を右クリックし、「新しいスキーマ」を選択し、名前に「sample」を入力して「OK」をクリックします。 「スキーマ」→「sample」から「テーブル」 を右クリックし、「新しいテーブル」 を選択します。 テーブルに「login」と名前をつけます。 「列」タブから「追加」 を選択し、カラムを追加します。 名前に「user_id」、データ型に「character varying」、長さに「10」を入力して「OK」を繰り句します。 同じように「password」を追加します。 「制約」タブから「主キー」の「追加」をクリックします。 主キー画面の「列」タブのボックスから「user_id」を選び、「追加」をクリックし「OK」をクリックします。 「OK」をクリックします。 「login」テーブルを右クリックし「データビュー」→「全ての列を表示」を選択します。 ここで↑の値の入力をしてください。入力し終わったら右上の×から閉じてください。(最初にデータを入れたときのみ自動で保存されます) 下記のファイルをダウンロードしてください。 #ref error :ご指定のファイルが見つかりません。ファイル名を確認して、再度指定してください。 (LoginServlet.java) #ref error :ご指定のファイルが見つかりません。ファイル名を確認して、再度指定してください。 (LoginConfirmServlet.java) #ref error :ご指定のファイルが見つかりません。ファイル名を確認して、再度指定してください。 (LoginDB.java) #ref error :ご指定のファイルが見つかりません。ファイル名を確認して、再度指定してください。 (UserBean.java) #ref error :ご指定のファイルが見つかりません。ファイル名を確認して、再度指定してください。 (login.jsp) #ref error :ご指定のファイルが見つかりません。ファイル名を確認して、再度指定してください。 (loginSuccess.jsp) #ref error :ご指定のファイルが見つかりません。ファイル名を確認して、再度指定してください。 (loginFail.jsp) ダウンロードしたファイルを基本構造通り配置してください。 ******************** ***ディレクトリ構成*** ******************** Sample | +---WEB-INF | +---src | | | +---Login | | | +---LoginServlet.java | LoginConfirmServlet.java | LoginDB.java | UserBean.java | +---classes | | | +---Login | | | +---LoginServlet.class | LoginConfirmServlet.class | LoginDB.class | UserBean.class | +---lib | +---web.xml | login.jsp loginSuccess.jsp loginFail.jsp コマンドプロンプトを開いて「LoginServlet.java」と「LoginConfirmServlet.java」と「LoginDB.java」と「UserBean.java」をコンパイルをします。 「sample」フォルダをつくり↑のように配置したら、最初に「SampleDB.java」をコンパイルします。コンパイルのときは以下のコマンドを入力してください。 javac -d . SampleDB.java コンパイルをしたときに注意が出るかもしれませんが、無視してかまいません。たぶんコンパイルはされて「sample」フォルダができてその中に「SampleDB.class」ファイルが生成されているはずです。 同じように「SampleServlet2.java」もコンパイルします。コマンドは以下のとおりです。 javac -d . SampleServlet2.java パッケージ以下をコンパイル javac -d . *.java 「SampleDB.class」と「SampleServlet2.class」ファイルを「classes」フォルダに移動します。 「web.xml」、「Sample.xml」を記述します。詳細は上の接続方法(DataSource)※推奨の項目7までを見てください。 パッケージの記述例 servlet-class ~ /servlet-class のみsample.LoginServletに書き換え、他はLoginServletに書き換える。 Tomcat を起動して http //localhost 8080/Sample/servlet/LoginServlet にアクセスします。 これでログイン認証は終了です。
https://w.atwiki.jp/pjsvr2007/pages/12.html
認証にフォーム認証を選択し、SQLサーバに認証を任せる場合(AspSqlNetMembershipProvider)、パスワード文字列にはデフォルトできつい制限がかかってしまう。これを変更する方法は以下の通り。 基本 http //technet2.microsoft.com/Office/ja-JP/library/559cc03c-56f7-4399-ad28-15ac35e8723d1041.mspx?mfr=true APS.NET の machine.config を参照する C \WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG にある machine.config を見て、以下の記述を探す。 providers add name="AspNetSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="LocalSqlServer" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="true" applicationName="/" requiresUniqueEmail="false" passwordFormat="Hashed" maxInvalidPasswordAttempts="5" minRequiredPasswordLength="7" minRequiredNonalphanumericCharacters="1" passwordAttemptWindow="10" passwordStrengthRegularExpression="" / /providers このうち、必要な設定を書き換える。ただし、machine.config を書き換えると、ASP.NETアプリケーション全体の 設定が変わってしまうので注意すること。必要であれば、各web.configでこの設定を上書きするようにする。 各パラメータの意味についてはこちらが参考になる。
https://w.atwiki.jp/ketsupedia/pages/358.html
ログイン時に入力する画像認証で 気になる文字列が表示されたら撮影して記録するくだらないページ。 「二度抜くわ!」 一体何を抜こうと言うんです? 「マゾなユイ」 ユイ・・・一体誰なんだ・・・。 幻想戦姫関係でユイと言えばあの人だが・・・!? (´・ω・`)ぎぎぎ 「居座るぜ」 頑張れよ 「ゴミの鳥」 見ろ!鳥がゴミのようだ!
https://w.atwiki.jp/evaluation/pages/34.html
専門職大学院の認証評価 根拠法 学校教育法第109条第3項 専門職大学院を置く大学にあっては、前項に規定するもののほか、当該専門職大学院の設置の目的に照らし、当該専門職大学院の教育課程、教員組織その他教育研究活動の状況について、政令で定める期間(5年以内)ごとに、認証評価を受けるものとする。ただし、当該専門職大学院の課程に係る分野について認証評価を行う認証評価機関が存在しない場合その他特別の事由がある場合であって、文部科学大臣の定める措置を講じているときは、この限りでない。 専門職大学院の認証評価機関 分野 認証評価機関 認証日 法科大学院 財団法人日弁連法務研究財団独立行政法人大学評価・学位授与機構財団法人大学基準協会 H16.08.31H17.01.14H19.02.16 経営 特定非営利活動法人ABEST21財団法人大学基準協会 H19.10.12H20.04.08 会計 特定非営利活動法人国際会計教育協会 H19.10.12 助産 特定非営利活動法人日本助産評価機構 H20.04.08 臨床心理 財団法人日本臨床心理士資格認定協会 H21.09.04 教員養成 教員養成評価機構 H22.03.31 公共政策 財団法人大学基準協会 H22.03.31 情報、創造技術、組込技術、原子力 一般社団法人日本技術者教育認定機構(JABEE) H22.03.31 ファッション・ビジネス 財団法人日本高等教育評価機構 H22.03.31
https://w.atwiki.jp/lmes2/pages/192.html
Squid で BASIC認証 概要 タイトルのまんま。 前提条件 Squid インストール 手順 「c \squid\etc\squid.conf」をエディタで編集する。 BASIC認証に関する設定をコメントアウトし、 「auth_param basic program」に、「認証に使用する外部プログラム」と「パスワードファイル」を指定する。 (区切りが「\」ではなく「/」であることに注意) #auth_param basic program uncomment and complete this line #auth_param basic children 5 #auth_param basic realm Squid proxy-caching web server #auth_param basic credentialsttl 2 hours #auth_param basic casesensitive off ↓ auth_param basic program c /squid/libexec/ncsa_auth.exe c /squid/exc/passwd #ここ編集 auth_param basic children 5 auth_param basic realm Squid proxy-caching web server auth_param basic credentialsttl 2 hours auth_param basic casesensitive off 認証に使用するユーザの指定に関する設定をコメントアウト。 #acl password proxy_auth REQUIRED ↓ acl password proxy_auth REQUIRED 「localnet」(LAN内からの接続としてのACL)を禁止し、 「password」の接続を許可。 これをしないと、LAN内からのアクセスに対し、BASIC認証をせず許可してしまう。 http_access allow lan ↓ #http_access allow lan http_access allow password # 追加分。 「squid.conf」の編集は以上。 「c \squid\etc」に「passwd」(拡張子はなし)というファイルを作成し、 htpasswd用パス作成ツール - phpspot 等を使って、ユーザ名と暗号化されたパスワードを記述する。 下記の例は、ユーザ名「hoge」パスワード「hoge」で作成した。 not found (486.jpg) サービスを再起動。 not found (487.jpg) 以上でBASIC認証の設定は完了。 このプロキシサーバを使用してIE等を利用すると、以下のような認証画面が表示される。 not found (488.jpg)