proxy環境下でyumやpipなど使いたいときにはproxy設定を入れるが、proxyに認証があるとユーザ名・パスワードも入れないといけないので、下記の形式で環境変数を設定したりする。 (Windowsの場合の例) set HTTP_PROXY=http://username:password@proxyhost:port set HTTPS_PROXY=http://username:password@proxyhost:port
proxy環境下でyumやpipなど使いたいときにはproxy設定を入れるが、proxyに認証があるとユーザ名・パスワードも入れないといけないので、下記の形式で環境変数を設定したりする。 (Windowsの場合の例) set HTTP_PROXY=http://username:password@proxyhost:port set HTTPS_PROXY=http://username:password@proxyhost:port
今朝、懐かしい方からメールがあって私はiPhoneをまじまじと見つめてしまいました。それはこのブログにも以前登場した「一流の研究者」の、私の師匠です。 しかしメールの内容はおかしなものでした。「いま海外にいるのだが、同行していた人が急病になってしまい、手術にお金が必要なので送ってくれないか」という内容で、つまりは詐欺メールです。 シグネチャまでも真似ていますが、誰かが師匠のメールアドレスを乗っ取ったのです。### 2段階認証を使おう 師は周囲にコンピュータのウィザードが大勢いますのできっと適切に対応がとられているものと思います。 しかし一度アカウントが乗っ取られると、住所録も含めて奪われてしまいますのでいつまでも自分の名前を騙って友人、親戚にこうした詐欺メールが送られるリスクが続きます。 私の周囲でも今年に入ってGmailが乗っ取られてこうした詐欺メールが飛んできたというケースが複数ありま
次に認証を行うユーザーの管理方法について確認します。ユーザーの管理方法をレルムと言います。 レルムの指定は「server.xml」ファイルに記述します。このファイルは「(Tomcatがインストールされたディレクトリ)\Tomcat 5.5\conf\」ディレクトリにあります。 レルムに関する部分だけを抜粋してみます。 <!-- Define the top level container in our container hierarchy --> <Engine name="Catalina" defaultHost="localhost"> <!-- This Realm uses the UserDatabase configured in the global JNDI resources under the key "UserDatabase". Any edits that a
2011/03/10 「パスワードポリシーはますます複雑化し、ユーザーの大きな不満の原因となっている。再発行などに対応するヘルプデスクの手間、コストも大きい」――。 日本ベリサインは3月9日、認証ソリューションに関する説明会を開催した。米シマンテックのユーザーオーセンティケーション担当バイスプレジデント、アトリ・チャタジー氏は、パスワード認証にまつわる問題点をこのように指摘し、より強固で高度な認証が求められていると述べた。 ベリサインは2010年9月から11月にかけて、フォレスターリサーチに委託し、企業における認証の現状について調査を行った。北米の306社を対象としたこの調査からは、パスワードポリシーがますます複雑化していること、それにともない企業のヘルプデスクの負荷およびコストが高まっていることが明らかになった。 例えば、回答企業のうち87%では2つ以上の、27%は6つ以上のパスワードを
OAuth 2.0で Webサービスの利用方法はどう変わるか ソーシャルAPI活用に必須の“OAuth”の基礎知識 株式会社ビーコンIT 木村篤彦 2011/2/2 TwitterがOAuth 1.0を採用したのを皮切りに、今では多くのサービスがOAuth 1.0に対応しています。国内でも、例えば、マイクロブログ型コラボツール「youRoom」、小規模グループ向けグループウェア「サイボウズLive」、「はてな」のいくつかのサービス、「Yahoo!オークション」、リアルタイムドローツール「Cacoo」などがOAuth 1.0に対応したAPIを公開しています。 ここ数年でOAuthはさまざまなWebサービスのリソースを利用する際の認証方式として普及してきました。これは大きなプレーヤーがサポートしたことも一因ですが、OAuthの持つ以下の2つの特徴によって、「OAuthを使うと、サービスプロバイ
Tomcatのtomcat-users.xmlのユーザ情報を用いた認証 この方法はもっとも簡単に認証をかける方法である。 ただし、ウェブアプリケーションからユーザの追加、情報の修正を行う場合はこの方法は使うことはできない。 web.xmlの設定 <security-constrait>で認証をかける場所と認証される利用者やロールを設定する <web-resource-collection>以下の<url-pattern>で認証を行う場所を設定する。"*.jsp"でjspファイルすべてや"<フォルダ名>/*"であるフォルダ以下すべてのファイルなど柔軟な設定が可能である。 <login-config>で認証方法を設定する 以下にweb.xmlで認証に関する設定例を示す。 <security-role> <role-name>user</role-name> </security-role> <
「アクセス制限をweb.xmlの記述だけで実現する」でも紹介したように、コンテナの標準機能を利用することで、設定ファイルへの記述だけで認証機能を実現することが可能になります。 しかし、認証ダイアログが表示されるだけの認証機能では、いささか物足りないとは思いませんか? アプリケーションによってはトップページとしてロゴを入れたい場合もあるかもしれませんし、そもそも新規ユーザーのためにユーザー登録をナビゲートするなど、お知らせメッセージなどを表記したい場合もあるでしょう。 このようにログインページのカスタマイズを行いたいという場合には、フォーム認証を利用すると便利です。フォーム認証を利用することで、ログインページとして自由にデザインされた独自ページを採用することが可能になります。 操作手順 (1)デプロイメントディスクリプタを定義する 「アクセス制限をweb.xmlの記述だけで実現する」で定義し
アプリケーションに認証機能を追加したいと思った場合、もちろん、自分で認証機能を実装することも可能です。しかし、コンテナ(Tomcat)にあらかじめ用意されている機能を利用することで、より簡便に(しかも確実に)認証機能を実現することができます。 操作手順 (1)デプロイメントディスクリプタを定義する Tomcatの認証機能を利用するには、デプロイメントディスクリプタ(web.xml)に以下のように認証の定義を記述するだけです。 ただし、すでになにかしらの記述のあるweb.xmlに追記する場合には、任意の個所に追加することはできませんので、注意してください。 <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.
Webアプリのセキュリティを検討する「Webアプリケーションセキュリティフォーラム(WASForum)」が5月22日、認証と認可に関するイベントを開催した。その中で携帯電話の「かんたんログイン」のセキュリティに関して講演が行われた。 WASFは、もともとPCの一般的なインターネットのセキュリティを対象にしていたが、昨今のスマートフォンの流行などで携帯電話からも通常のインターネットが頻繁に利用されるようになったことから、今回のような考察が行われたという。 かんたんログインに関して講演をしたのは、HASHコンサルティングの徳丸浩氏と、産業技術総合研究所(産総研)の高木浩光氏。 パンドラの箱を開いたキャリア 携帯電話のWebサイト(携帯Web)で一般的に利用される「かんたんログイン」は、iモード(NTTドコモ)やEZweb(au)、Yahoo!ケータイ(ソフトバンクモバイル)で利用されているログ
「おーおーっすっ!」 てなこって、TwitterのAPIのBASIC認証も6月末に終了してOAuth/xAuthに移行するというこの時期に、あらためてOAuthについて勉強してみたんですのよ? OAuth認証を利用するライブラリは各言語で出そろってきてるのでそれを使えばいんじゃまいか? というと話が終わるので、じゃあそのライブラリの中身はなにやってんのよってことを、OAuthするScalaのライブラリ作りながら調べたことをまとめてみました。 間違っているところもあると思うのでツッコミ歓迎です>< OAuthってそもそもなんなの? ものすごくざっくりというと「API利用側が、ユーザ認証をAPI提供サービス側にやってもらうための仕様」って感じでしょうか? BASIC認証の場合、API利用側が認証に必要なアカウントやパスワードを預かる必要があるわけです。悪意のあるAPI利用側が「なんとかメーカー
This shop will be powered by Are you the store owner? Log in here
携帯サイトでのセッション管理 今回は携帯で会員サイトを作る時のベースとなるログイン状態の管理方法を見ていきたいと思います。セッションとはユーザーがサーバーに接続し、サイトを巡回している間アクセスしてきているのが同一利用者であることを認識するための仕組みです。この仕組みを利用することで、一度会員ログインが完了した利用者がサイトにアクセス中、継続的に自分だけの情報を見るといったことが実現可能になります。 図1 セッションの仕組み セッションを維持するためには、セッションIDを利用します。通常セッション管理はアクセスしてきた端末に対してセッションIDを割り振り、ブラウザに対して割り振られたセッションIDを渡します。サイト側はそのセッションIDに紐付いた情報を保持しておき、アクセスしてきたブラウザのセッションIDを元に情報を引き出すといった仕組みになっています。 ブラウザがセッション管理を行う方法
はじめに OpenIDは最近非常に注目が高まっている認証技術の一つです。ここでは、OpenIDを利用したPerlのサンプルを通じてOpenIDのメカニズムに触れていきたいと思います。必要な環境 Perl 5.8以上が動作する環境が良いと思います。基本動作の確認はMac OS Xを利用しましたサンプルの紹介 早速サンプルコードの「openid-test.cgi」を見ることにしましょう。このサンプルはOpenIDを利用した簡易ログインページです。 #!/usr/bin/perl use strict; use warnings; use CGI; use Net::OpenID::Consumer; #use LWPx::ParanoidAgent; use LWP::UserAgent; my $query = CGI->new; $query->charset('utf-8
本書では認証関連の記述は、「ひとまずBASIC認証を使っておきましょうね」でお茶を濁してしまったが、ここでもうちょっと細かい認証周りの話について説明しておく。 一般的な認証では、秘密のパスワードを入力し、それがサーバーに記録されているパスワードと合致する→認証を通る、ということになる。複数のユーザーを判別する場合は、ユーザーを特定するIDとそれに対応したパスワードの組み合わせで認証することになる(ユーザーが1人しかいないならばパスワードだけで認証できる)。 もっとも単純な認証のサンプルを書くと、以下のようになるだろう。 login.html <form method="POST" action="login.php"> ID: <input type="text" name="userid" size="15"><br> パスワード: <input type="password" n
「認証処理の基本」では、どのようにすれば安全に認証処理を実装できるのか説明した。しかし、実際には認証処理を通ったあとに、その状態を持続する必要がある。ここでは認証の結果をどのようにして保存するか説明する。 認証状態を保存する方法としては、Cookieを利用する方法と、セッションを利用する方法の二つが一般的だ。セッションといっても、実際には内部でCookieを使っていたりする(使わない方法もある)のだが、ひとまず細かいことは気にしないでおこう。まずCookieを利用して認証状態を保存する方法を説明する。 Cookieを利用して認証状態を保存する一番シンプルな方法は、以下のようなコードとなる。 <?php $userid = isset($_POST['userid']) ? $_POST['userid'] : ''; $pwd = isset($_POST['pwd']) ? $_P
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く