リモートアクセスAPI利用の際の権限設定について

[Noriko Iwai]

お世話になります。

先日は、リモートアクセスAPIをこちらで教えていただき、ありがとうございました。
おかげさまで目的の処理を実現できそうです。

これに関連して、一点質問があります。

リモートアクセスAPIの利用に際して、[権限設定(プロジェクト単位)の有効化]から、匿名ユーザーへのRead権限を渡しています。
これをしていると、ログインをしていないユーザにもジョブ名が見えてしまいますが、Read権限をつけずにリモートアクセスAPIを利用する方法はある
のでしょうか？

wget --http-user=ユーザー名 --http-passwd=パスワード リモートアクセスAPIのURL
ではできないようでした。

よろしくお願いいたします。

[Akiko Takano]

こんにちは。

Jenkinsじゃないのですが、他のCGIで認証をパスさせようとしたとき、wgetのオプションではどうもうまくいかず、curl -u を使ったことがあります。

こちらだと認証が通るようです。

curl -v でヘッダも含めてチェックすると、こんな感じです。

* About to connect() to hudson-master.bob.iiji.jp port 80
* Trying 10.110.103.45... connected
* Connected to hudson.xxx.xxx (nnn.mmm.nnn) port 80
* Server auth using Basic with user 'akiko'
> GET /job/api/xml/?depth=1 HTTP/1.1
> Authorization: Basic ユーザ名＆パスワード文字列をBase64化したもの
> User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5

Jenkinsそのものでお役に立てずにすみません....

2011年8月3日11:17 Noriko Iwai <noriko.h...@gmail.com>:

[Noriko Iwai]

すみません。自己解決です。

request = urllib2.Request(url)
base64string = base64.encodestring('%s:%s' % (ユーザー名, パスワード))
request.add_header("Authorization", "Basic %s" % base64string)
response = urllib2.urlopen(request)
body = eval(response.read())

にて取得することができました。

[kooo96]

こんばんは．
すでにお分かりかと思いますが，忘れやすいが以下を理解しておけばよいと思います．

● HTTP の標準手順（チャレンジ方式）

URL 指定で要求送信
  （サーバー）認証必要なら「404? 認証エラー」を返す(Basic 認証を要求）

認証情報の入力プロンプト表示，Basic認証情報を付けて再要求
  （サーバー）正しければ認証OK
  （サーバー）認可チェック．エラーなら「403? 認可エラー」を返す

wget や curl などもこの手順がたぶんデフォルトで，
ユーザー名・パスワードを付けても，最初はそれらが送信されないことに注意．

● Jenkins や Trac など（いきなり認証情報を付けて要求）

認証情報を付けて URL 指定で要求送信
  （サーバー）認証エラーでも「404? 認可エラー」を返し，ログイン画面を表示
  （サーバー）認可エラーならそのむね表示

curl は知らないのですが，wget では --auth-no-challenge を付けると
この動作になります．
@see https://wiki.jenkins-ci.org/display/JENKINS/Remote+access+API

Noriko さんが自己解決できたのも「いきなり認証情報を付けて要求」
したからと思われます．

なお現在自宅からで手元に *nix マシンとか資料とかないので，
詳細や間違いはご容赦ください．

ではまた．
K96

2011年8月3日11:58 Noriko Iwai <noriko.h...@gmail.com>:

[Noriko Iwai]

kooo96さん

こんにちは。

詳しい説明ありがとうございます。
教えていただいた通り、--auth-no-challengeをつけたら認証が通りました。
おかげさまで色々と疑問が解けました^^;

是非今後役立てていきたいと思います。
ご親切にありがとうございました。

On 8月3日, 午後7:13, kooo96 <koo...@gmail.com> wrote:
> こんばんは．
> すでにお分かりかと思いますが，忘れやすいが以下を理解しておけばよいと思います．
>
> ● HTTP の標準手順（チャレンジ方式）
>
> URL 指定で要求送信
> （サーバー）認証必要なら「404? 認証エラー」を返す(Basic 認証を要求）
>
> 認証情報の入力プロンプト表示，Basic認証情報を付けて再要求
> （サーバー）正しければ認証OK
> （サーバー）認可チェック．エラーなら「403? 認可エラー」を返す
>
> wget や curl などもこの手順がたぶんデフォルトで，
> ユーザー名・パスワードを付けても，最初はそれらが送信されないことに注意．
>
> ● Jenkins や Trac など（いきなり認証情報を付けて要求）
>
> 認証情報を付けて URL 指定で要求送信
> （サーバー）認証エラーでも「404? 認可エラー」を返し，ログイン画面を表示
> （サーバー）認可エラーならそのむね表示
>
> curl は知らないのですが，wget では --auth-no-challenge を付けると
> この動作になります．

> @seehttps://wiki.jenkins-ci.org/display/JENKINS/Remote+access+API

>
> Noriko さんが自己解決できたのも「いきなり認証情報を付けて要求」
> したからと思われます．
>
> なお現在自宅からで手元に *nix マシンとか資料とかないので，
> 詳細や間違いはご容赦ください．
>
> ではまた．
> K96
>

> 2011年8月3日11:58 Noriko Iwai <noriko.harash...@gmail.com>:

[K96]

K96です．

お役に立てれば幸いです．小さなことでもすっきり分かるというのは本当に気持ちいい～ですもんね．
以下ちょっとだけ補足．

● HTTP の標準手順（チャレンジ方式）

この手順の最大の欠点は，ログアウトやユーザー名をかえて再ログインなどがエレガントにできないことです．
できることはできるのですがHTTP やブラウザの癖を理解していないヒトだと絶対パニックになります！

なお私はつい最近までこの手順がHTTPとして絶対正しいと信じていました :-)

● Jenkins や Trac など（いきなり認証情報を付けて要求）

こちらはHTTPの標準／正規手順ではないけど，実用的な解決です．
ブラウザのプロンプトでなく，フォーム画面でログインする Web アプリ
・かつ，コテコテのWebアプリでなく，(REST型)のWebサービスを多少とも意識して作成されたWebアプリ
では，現在頻繁に使用されていると思います．

特に Jenkins のリモートアクセスAPIは強力で，いろいろ活用できるはずです．

ではまた．
K96

[Akiko Takano]

便乗で恐縮ですが、常々不思議に思っておりましたので、ご説明いただいて大変勉強になりました！

JenkinsのAPIも含め、その他の認証付きサービスに関しても、とても参考になりました。
（ほんとにスッキリしました）

トピ主さま、K96さま、ありがとうございました。

2011年8月4日18:57 K96 <koo...@gmail.com>: