「curl」を含む日記 RSS

はてなキーワード: curlとは

2019-08-30

[]内容

 筋トレ内容

単位ポンド(1ポンドは450グラムくらい)

💪

ドロップセット法採用した。セットを追うごとに少しずつ負荷を減らしている。

 ボリューム

10回 × 1-4 セット

Beg.Nov.Int.Adv.
chestpress64102153215
HLP135218327456
SLC5389137196
LPD70101139183
SR74106144189

unit is lb, HLP, horiz. leg press, SLC, seated leg curl, LPD lat pull down, SR, seated rowing

💪

これを見ると 標準値範囲に入っていることが分かる♡

 感想

歯科医院に出向かねばならなかったから、開館直後から20分だけ取り組んだ。時間有効活用できた自分に酔いしれている。そんなことで自分をほめてあげたく成れるなんて単純だな。

💪

レッグプレスときは、10回でワークアウトせず5回くらいできそうだったが、13回で(何を思ったか)やめてしまった。というか両足レッグプレスでワークアウトするまで回を重ねたことあるだろうか?

2019-07-12

CURLPHPGET配列を渡すときエラーになる

?arr%5B%5D=foo&arr%5B%5D=baa

要はURLエンコードしないと駄目

PHPGETパラメーターのパラメータプレフィックスとしてをつけると配列として受け取れるが、コマンドラインcurl実行時にURLに直接を記述するとエラーになる

2019-04-16

http://b.hatena.ne.jp/entry/4667308515376875202/comment/akulog

だってボットネットからcurlを一斉に打ったらDDoSで威力業務妨害だけどな

道具を使って "どのような行為を行ったか" が犯罪とそうでないかを分けてるんだよ

エンジニアの遵法意識の化けの皮が剥がれた事件だわ

2019-03-22

講評

 足

レッグエクステンション (Ext) 100

シーテッドレッグカール (Curl) 90

レッグプレス 60

単位キロなの?

ごめん、ポンドって書いてあったね。

だとすればレッグプレスがめっっっっちゃ軽すぎる。

絶対もっと出来る。

レッグカールよりレッグプレスの方が軽いなんて言う人類はいない。

動作ゆっくり戻すように。


ラットプルダウン (LPD) 80

シーテッドロー (SL) 70

それらの種目は背中です。

胸じゃ有りません。


 体組成

体脂肪率23

BMI 約26

基礎代謝 1780

なんとなく基礎代謝が下がってる!!なぜだ?筋肉量が増えたら代謝が増えるんとちがうんか?

組成計って適当からあんまり真面目に気にしなくていい。

同じ時に連続2回測ったら結果が違うし、水を飲んでからやるだけでバーンと違うし。

あくまで目安というか気分。


anond:20190322153922

今日筋トレ内容

単位ポンド

 足

 腹

 背中

 胸

 回数とセット数

基本10回、3セットずつ。ローは、持ち手のパターンが2種類あるので、4セットにした。トルソーは、左右あるから6セット。

 体組成

 高強度インターバルトレーニング

トレッドミルで、レベル10(速度一定で斜度が時折変わるプログラム).速度6.6キロ/時。13分

2019-03-20

今日筋トレ内容

単位ポンド今日スマホ忘れたので、記憶に基づく(ちっと あいまい

 足


 腹


 胸


 回数とセット数


基本10回、3セットずつ。ローは、持ち手のパターンが2種類あるので、4セットにした。トルソーは、左右あるから6セット。

 体組成

2019-03-17

今日筋トレ内容

単位ポンド

 足


 腹


 胸


 回数とセット数


基本10回、3セットずつ。ローは、持ち手のパターンが2種類あるので、4セットにした。LPDは5セット。トルソーは、左右あるから6セット。

 その他

 タバタ

トレッドミルでHIIT(タバタ)やってみた。レベル10を選んだ。相変わらず速度は、時速0.8キロ。手動で約6キロ/時まで上昇。

最高斜度=15、インターバルの間は4.5。どうもレベルは、10までしかない。

 ストレッチ

妻子がお稽古ごと・買い物ということで結局2時間滞在。暇なので、ストレッチも。ドローイングと寝てる状態から立ち上がる練習した。

 体組成

2019-03-15

今日筋トレ内容

単位ポンド

 足


 腹


 胸


 回数とセット数


基本10回、3セットずつ。ローは、持ち手のパターンが2種類あるので、4セットにした。トルソーは、左右あるから6セット。

 その他

トレッドミルでHIIT(タバタ)やってみた。最初手で速度を変えようとしたが、面倒になった。そんなときインターバル」というプログラム発見!!!!!

レベル8を選んだ。速度は、時速0.8キロで、高強度の間は斜度が上がる(最高=12だったっけ?)、インターバルの間は4.5.速度は0.8で固定みたいだったんで、自分で6.5まで上昇させた。

結構効果的だった。帰り道フラフラだった。

 デフォルトの速度が遅いのは なんとかならないもの

どうもレベルは、25くらいまであるようだ。次は、最高レベルセレクトしよう。行きつけのジム限定で言えば、タバタやるなら、エアロバイクよりもトレッドミルの方が適性がありそうだ。

2019-03-13

今日筋トレ内容

単位ポンド

 足


 腹


 胸


 回数とセット数


基本10回、3セットずつ。ローは、持ち手のパターンが2種類あるので、4セットにした。トルソーは、左右あるから6セット。

 その他


バイクでHIITもどきをやった。20秒間の最高強度の間、回転数が100を超えて警報が鳴りまくっていた。しかも負荷が途端にゼロになる。

なんとかならないものか?

2019-03-06

今日筋トレ内容

単位ポンド

 足


 腹


 胸


 回数とセット数

基本10回、3セットずつ。トルソーは、その倍取り組んだ。左右あるから

あと勾配ベンチで、クランチに取り組んだ。アブド後だったからか10×2でダウン⤵

顔と名前が一致しない症候群


マシン名前を見ても、どういうものだったか思い出せない。

2019-02-05

遅まきながら、転生したくなってrustでwebassemblyなんか始めてみようと職場PCで内職開始。。。のはずがWSLでrustup-intがうまくいかない。

proxy環境からかな?と思うもそれならcurlでこけるはずだ。

default host tripleという聞きなれない設定がstable-x86_64-"unknown"-linux-gnuからなのかとCustomize installationをいじるもうまくいかない。

なんやねん、一生java6で腐ってろと言う貧乏神なのかと毒づいたら下記に書いてあった。

https://github.com/rust-lang/rustup.rs/issues/1529

"The situation has been occured in the office, which has proxy and self-trusted certificate."

...やっぱり自社のプロキシ問題かよ。MTTMで今もばっちり解析されているのかよ。オレオレとかまじやめてよ。。

書いてあるとおり、git config http.sslVerify false入力したらばっちりうまくいった。

@sshplendidさんはどうやって気づいたのだろう。あなたは神だ。最高。

。。。環境構築に手間取りすぎて早くも心が折れそう。今日は帰る。

2018-12-01

anond:20181201195506

はてなー老人会を含むインターネット老人会の面々はwgetとかcurlとかで組んだ秘伝のタレ化したWebクローラスクリプトを持っているから実際は面倒じゃ無いんだよ

2018-05-24

anond:20180524113936

そうじゃなくて、プログラマ美徳的な話をしている。

だってキーボードをたたき続ければいつかはシェイクスピアが書けるが、プログラマシェイクスピアを書くためにはcurlシェイクスピアの原文が書いてあるソースダウンロードするだけでいい。

そこをがんばってソース上にシェイクスピア文章を書こうとしたりすることを、我々からすると「無駄コード」という。

最小の努力で最大限の効果を生み出せるように努力しんさい。努力しないでいい努力を。

2018-04-24

anond:20180424104238

んでも今ワイが使ってるAWSインスタンスから普通にcurl打つくらいなら疎通するし、DNSで弾いてる以外のことはしてないと思う。

多分googleDNSフィルタリングしてんだな。

2018-01-31

anond:20180130221601

一番最初Homebrewを落としてくるときなんだけど、素のOSX LoinのcURLを使ってHomebrew用のcURLを落とす過程で、セキュリティ接続エラーが起きてるみたいだ。

困らないケースって、その人がHomebrewを導入したタイミングではまだレポジトリが高いセキュリティ要求してなかったとか、

あるいはFinkMacPortsから移行する場合、新しめのOpenSSLcURLを入れていたかセキュリティ接続ができたんじゃないか、と思う。

とにかく、素のLioncURLHomebrewcURLを落としてこれない。セキュリティ証明書問題かもしれないが、そのあたりはよく分からいからなんかもういいってなってる。

なんせ、brew doctorはLionってだけで警告を出すし、どうも10.8以上が推奨環境じゃなかろうかと。

2018-01-30

HomebrewMacPortsかってやつ

最近事情ではOSX lionまではMacPorts一択ってことでいいんだろうか。

Homebrewインストール段階で、Curlの7.58.0が入ってこない。opensslパスを通しておいても、結局いろいろダメ

MacPortsだとCurlがちゃんと入る。

2018-01-25

WindowsでPython2系でUnicode

最悪な組み合わせだということに気づいた

64bitだから入れたAnaconda(というかSpyder)は

コンソールなりエディタなりどこかしら化けるし

でもまたPyCharmで頑張れるほど元気はないし

もうUnicode扱うときはRでいいかな…

RはRでcurlうまいこと扱えなくて禿げそうなんだけどさ…

2018-01-03

Qiita無能を見分けるたった一つの方法

hogehogeの紹介

hogehogeの使い方を紹介します。

インストール

まずはインストールします。

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

2017-05-02

マストドンAPI

マストドンリポジトリ

ttps://github.com/tootsuite/mastodon

マストドンAPIリファレンスAPI実装済みのライブラリ(サードティ)の紹介

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md

マストドンAPIに関するドキュメントが置いてあるディレクトリ(色々ある)

ttps://github.com/tootsuite/documentation/tree/master/Using-the-API

マストドンアプリ認証にdoorkeeperを使ってるので認証APIはこっちを参照する必要がある

ttps://github.com/doorkeeper-gem/doorkeeper/wiki

マストドンドキュメントで紹介されてるAPI実装済みのライブラリ(サードティ)を使うのが一番ってっとり早い

以上

=====

わざわざ自前でAPIを叩くコードを書く

step1

アプリマストドンサーバー登録する

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#apps

POST /api/v1/apps

必要データをPOSTするだけ、難しくない

アプリ登録をわざわざコーディングする場合ライブラリとして作って提供する場合くらい(?)

(アプリ複数インスタンス対応させる場合はやはりコード書くしかないけど)

(登録したIDを自前サーバーで持って同一アプリで共有するとか?)

別にhtmlフォーム作って送信するだけでも登録できる

(ローカルhtmlファイル作ってブラウザ表示して必要入力してsubmit送信するだけ簡単)

<form name="regsterapp" method="POST" action="http://SERVERNAME/api/v1/apps">

<input name="client_name" type="text" value="">

<input name="redirect_uris" type="text" value="urn:ietf:wg:oauth:2.0:oob">

<input name="scopes" type="text" value="read write follow">

<input name="website" type="text" value="">

<input type="submit"></form>

step2

ユーザに対してのアプリ認証

doorkeeperについて知る必要がある

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/Testing-with-cURL.md

このページに書いてあるgrant_type=password認証法ではread権限しか貰えないぽい

grant_type=authorization_codeで認証する必要がある、これ読めば早い

ttps://github.com/doorkeeper-gem/doorkeeper/wiki/Authorization-Code-Flow

GET /oauth/authorize

必要パラメータ(※1)つけたリンクアプリ認証したいユーザに踏んでもらい許可を押してもらった上でそこで表示されるコード(RETURNED_CODE)を使う必要がある

(自前サーバーなどでリダイレクトで受け取ることもできるけど)

その表示されたコード(RETURNED_CODE)を使って次のAPIを叩くと認証完了する(アクセストークンをゲットできる)

POST /oauth/token

これもただのPOSTになるのでそんなに難しくない

さっきのアプリ登録みたいにhtmlとかで簡易にもできるけどアプリ秘密キーを使うので公開はダメでしょうな

※1

ttp://SEVERNAME/oauth/authorize?client_id=YOUR_CLIENT_ID&redirect_uri=urn:ietf:wg:oauth:2.0:oob&response_type=code&scope=read+write+follow

scopeというパラメータで取得したい権限指定する必要がある

step3

認証終わってアクセストークンをゲットしたらもうAPI使えるので

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/Testing-with-cURL.md

これの2番目に書いてあるようにHTTPのヘッダに Authorization: Bearer ACCESS_TOKEN を加えてから

APIの叩けばよい

toot(トゥート)はAPIドキュメントではstatusという表現になってる

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#statuses

POST /api/v1/statuses

がtootするためのAPI

2016-12-25

Sophos Homeman-in-the-middle attack を受けた

結論: Sophos Homehttps通信を乗っ取ってhttpで返してくる

2016-06-29

anond:20160629135046

右も左も分からんかったのと、python勉強たかったんで、

pythonによるウェブスクレイピング」っていう本読んでるんですよ

curlでもスクレイピングできるんすね。

curl自体初めて聞きました

簡単クローリングなら、curlの方がいいってことですね

本に従ってbeautifulsoap使ってますそれから本の内容的にデータ分析のためにmysql使い始めました


将来的には、クロールしてデータかき集めて、自動取引なんぞに取り組みたいと思ってまして。

からmysql使うのなれとくもいいんではないかと思ってます

素人判断なので、間違ってたら教えてください

2016-04-26

anond:20160426124418 続き

プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324

anond:20160426124418 の続き

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくありますGoogleOAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google場合、redirect_uri があっても、このエンドポイントウェブブラウザベースアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフロー標準的ブラウザ用のエンドポイントコピーする人が一切いなくなるはずがありません。それに加え、Google例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、アプリ認証情報 (client_id と client_secret) を盗んだ人ができる悪行にいくつか言及しています。以下に、この攻撃と組み合わせることで (これまで筆者の知る限り公表されていない) 危険行為を実行可能にする問題をいくつか取り上げますさらに皆様の独創性にかかれば、「秘密」のはずのものを盗んだ人が悪用できる方法は他にも発見できるはずです。

セキュアでないトークン

トークンベース認証は多くの開発者にとって新しい概念です。そのため誤解も多く、EVS のようなもの設計する開発者の中にも、ただ何かの設計ガイドライン (たとえば OAuth) に従って API の動作を決めれば、あるいは他のプラットフォームのしていることをコピーすれば、自分プラットフォーム自動的にセキュアになるはずだと考える人が少なくありません。しかし何かをセキュアにするには、その要素ひとつひとつを余さずセキュアにする必要があり、それらの組み合わせすべてをセキュアにする必要があり、全体の枠組みもセキュアにする必要があります。思い出してください、全体のセキュリティ強度はその弱点の強度に等しいのですから、何らかの大まかなフレームワークを固守することだけに頼りきって、その通りに使う限り何をやってもセキュアだ、などと安心するわけにはいきません。OAuth ベースフレームワークそれ自体は、その内部要素のセキュリティを確保することに関しては殆ど何もしてくれません (ある種の要素で、あからさまにセキュリティを害するものだけは別)。

トークンベースシステムで少しでもセキュリティらしさを出すには、最低でもトークン生成に暗号学的にセキュアな擬似乱数生成器 (CSPRNG) を使う必要がありますが、この話題はあまりよく理解されていません。さらに悪いことに、一般的スクリプト言語の適切な CSPRNG 用 API は非常に少なく、しかしそうしたスクリプト言語が、人気ある最新サービスの多くを設計する際の基礎となっていることが多いのです。

もし生成されるトークン予測可能であれば、攻撃者はトークンを推測するだけで別のユーザになりきって悪意ある行為をすることができてしまます。筆者は、fortune 500 クラス大企業による OAuth ベースサービス一種の単調増加 ID (おそらくデータベースフィールド?) をそのままトークンに使っているのを見たことがあります。他にも、生成されるトークンがすべて単調関数の出力のようなサービスもありました。よく調べてみると、それは現在時刻に基づく非常に単純なアルゴリズムでした。こうしたシステムでは、まず自分としてログインし、現在トークン ID を見て、その後の ID を予測すれば、続く任意ユーザになりかわってトークン交換その他の操作にそれを使うことができるでしょう。他のテクニックと組み合わせれば、もっと標的を絞った攻撃も可能です。

このクラス攻撃は前述のセキュリティ文書で「4.5.3. オンライン推測による新規トークン取得の脅威」や「4.6.3. アクセストークン推測の脅威」に分類されています。この問題には解決策があるとはいえ、現時点でこの間違いを犯しているサービスの膨大さと、この間違いの犯しやすさを考えると、任意OAuth ベースサービスが外部レビューセキュリティを証明してもらえる可能性はあまり高くありません。

本欄の主眼ではありませんが、乱数に対する攻撃の中には、セキュリティを固めた CSPRNG を使っていないと OAuth ベースサーバを完全に破壊してしまえるものもあります。こうした問題は他のシステムでも非常に困ったものではありますが、動作のすべてが乱数のやりとりの上に成り立っている普通OAuth 実装では、より一層この問題が際立ちます。こうしたトークンは EVS のサーバ側で生成され、「普通実装における」OAuth がよくやる使い方ではサーバ信頼性を奪い、関連するトークンすべての予測可能性を高めていきます。最新の攻撃手法を防げるセキュリティ強化 CSPRNG が用意できないのであれば、もっとハードルの低い別のプロトコルに乗り換えたほうが良いでしょう。

一方、一部の OAuth ベース実装乱数必要性クライアント側に移すような構造になっていることも注目しましょう。色んな意味で、これは問題を別の場所に移しただけではありますが、サーバ側のアタックサーフィスを減らすのは事実です。これによって、少なくとも情報強者利用者は、信頼できるサービスをセキュアに使うことが可能になります。ただし情報弱者脆弱なまま放置ですが。今回の例に当てはめてみると、この種のセットアップでは AFCP の開発者が頑張って EVS をセキュアに使えるようにすることと、EVS 自体が陥落する危険回避することは可能ですが、ABC や XYZ が EVS をセキュアに利用するかどうかは別問題です。

クロスサイトリクエストフォージェリ (CSRF)

本論に入る前に指摘しておきたいのですが、CSRF 攻撃はその名前に反して、外部サイトからスタートする必要はありません。CSRF 攻撃というのは、自サイトへのリンクユーザが貼れる、掲示板メッセージングソフトのようなサイト自体からでもスタート可能なのです。

色々な手法CSRF に立ち向かうべく設計された数々のテクニックフレームワークがあります。これらのシステムの多くは、OAuth ベースのもの統合すると使いものにならなくなったり、サイト攻撃さらしかねない行為を促すことがあります

CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装ユーザ特定の外部サイトから連れてくるよう要求しまから、この防御策は執行できません。OAuth サーバリダイレクトする膨大なサードパーティドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。

また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要がありますOAuth の背後にある原則ひとつOAuth ベースサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています理想認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。

転送元と転送先のどちらかだけの、部分的ホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能オンオフ中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者CSRF 対策フレームワークを一切使用できなくなります

OAuthCSRF 攻撃を防ぐ CSRF トークン指定するようにと、オプショナルな state パラメータ定義していますしかしながら、OAuth ベースサービス一般的state の長さや文字種を制限し、要求どおりそのままでさないことがあるようです。そこで、おかし互換性問題が起こるため、多くの OAuth ベースサービス利用者リダイレクトのエンドポイントにおける CSRF 防御をすべてオフにせざるをえない状況に追いこまれています。これは「10.14. コード・インジェクションと入力バリデーション」に分類されていますstate パラメータの別の懸念は、EVS 側で stateアクセスのある人はだれでも、リクエスト改竄して、それ以外はまったく有効なままのパラメータを付けて AFCP にブラウザを送り返すことができるという点です。

OAuth ベース API の利用者は、自分アプリサービス登録する際にひとつか複数の URI をカッチリ決めておくよう求められるという制限も課せられています。これは redirect_uri に使えるホワイトリスト URI です。この仕組みにひそむ重大なユーザビリティ問題は後述するのでひとまず措くとして、この制限のせいで開発者は、state パラメータや他の潜在的危険の伴うアイディア姑息な工夫をこらし、泥沼に沈んでいくはめになっています。多くの OAuth ベースサーバは、ホワイトリスト URI をひとつしか許可していなかったり redirect_uri との完全一致のみ有効パラメータの追加を認めなかったりしています。このせいで開発者たちは CSRF 対策フレームワークの利用をやめたり、あらゆる危険ものstate パラメータに詰めこもうとし始めたり、浅薄システムを自前で作り出したりしています。その結果、redirect_uri と state の組み合わせによってはユーザ不適切なページに誘導する危険性が出てきます。これは「10.15. オープンリダイレクト」に分類されます

こうしたリダイレクトの問題は、パラメータをしっかり認証していないせいで、それ自体悪用可能なのですが、これを前述の「OAuth サービスへの偽装」問題と組み合わせるとユーザ大惨事をもたらしかねません。盗んだ client_id と client_secret を使えば、悪いやつらは AFCP とまったく同じ情報認証できるので、本物の AFCP にも見ぬけないようなリダイレクトを作ることができます。また、悪意あるユーザも、本来自分の持っていない AFCP 内の権限を取得するような state パラメータの利用方法改竄方法を見つけることができるかもしれません。その際には、おそらく盗んだ認証情報も使うことでしょう。概して、「普通実装における」OAuth の低品質設計のせいで、また特定の分野に関する教育レベルが低い外部開発者の直面する問題のせいで、OAuth ベース利用者に対する攻撃はしばしば、本来あるべき状態よりもずっと容易になっています

ここで読む意義のあるものとして、さらに「3.5. リダイレクト URI」「3.6. state パラメータ」「4.4.1.8. redirect-uri に対する CSRF 攻撃の脅威」があります

章のまとめ

セキュリティに関して言えば、「普通実装における」OAuth仕事ぶりはとてもひどいです。OAuth が目指していると思われるセキュリティ目標の多くは、達成されていません。さらに、OAuth ベースサービスの中には、種々の攻撃に対して無防備でいることを利用者公然要求するものがありますサービスをセキュアに使える場合も、そのことが知られているとは限らず (サービス側の、トークン生成手法といった重要セキュリティ詳細が明文化されていないうえにクローズドソースなため)、OAuth は今なお多くの低品質プログラミング習慣を招いていますOAuth は外部の開発者を守る点でほとんど何もしませんが、そうした開発者が使っている各種フレームワークの方はといえば、こちらも真のセキュリティ提供していなかったり、厳しい自制と注意がなければセキュアに使えなかったりする代物です。

この記事についていえば、個人的蔓延していると思った問題の一部を取り上げたものに過ぎません。この中には、極度に低質な、一切 OAuth の規格で義務付けられていない慣習を、他所OAuth に使っているのを見たまま開発者コピーした結果というものもあります

OAuth ベースサービス開発者もその利用者側の開発者も、OAuth ベースプラットフォーム実装したり利用したりするためには、ここでリンクした文書をすべて読んで理解する必要があります。挙げられている 50 クラス攻撃も、各クラスの深刻度も完全に把握する必要がありますし、そのうえで「実装仕様書セキュリティガイドラインには漏れがないとは限らない」ことにも留意すべきです。この記事は公式文書にない問題をいくつか取り上げているとはいえ、OAuth セキュリティ問題の表面をなでているに過ぎないことも覚えておくべきです。ここに混ざって、公式 OAuth 提案に加えられる変更点はどれもまったく新たなセキュリティ問題を引き起こすものですが、残念ながら変更はよくあることなのです。そこで各々が、乱数生成やセキュリティ調査技術といった OAuth 以外のセキュリティ関連分野も理解していなければ、OAuth でそれなりのレベルセキュリティを実現することはできません。

真のセキュリティをお探しの方には、よそを探すようお勧めします。最後の章で OAuth の代わりになる選択肢をいくつか取り上げます

ユーザビリティ関連

(略: ふつう実装では、サービス側がプラグを引き抜くようにして自由利用者出禁にできる。ビジネス的にもまずいし、悪意あるユーザが API 利用者を騙って出禁になるとアプリへの DoS になる。)

(略: サービスからは API 利用者という大きすぎる単位しか見えないので、たとえばビデオカメラアプリ単位で利用帯域などを制限せざるを得ないが、そうするとそのビデオカメラは、一部ヘビーユーザのせいで他のユーザが締め出される事態になる。OAuth 以外のサービスならふつうユーザ単位対策としてユーザ開発者アカウントを取得してもらうのも面倒すぎる。ていうか手動プロセスを挟んでたり。)

(略: ふつう実装SaaS モデルしか見ていないので、URI を持たない AFCP のような社内ソフトや、ビデオカメラのようなデスクトップアプリには使えない。アプリcURL 的なもので API を叩こうとしても、JavaScript必要だと言い張るサービスもある。グローバル企業が地域別にドメインを分けていたら URI が足りない。客ひとりひとりにサブドメインを与える製品だと URI が足りない。足りるとしても追加・更新メタ API で簡単にできない。ひとつの URI ですべてのリクエストをこなすのセキュリティ問題もあり、ロードバランス等の必要性も出るし、社内ソフトデスクトップアプリに余計なウェブサイトへの依存性を加えることになる。httpサーバlocalhostで立てるとかアホか。)

(略: オープンソースしづらい)

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる

2015-04-15

FedoraSkypeを入れるのが簡単になった

基本的にはFedoraを気に入っているのだが、

Skypeflashなど一部ソフトの導入手順の面倒さがネックだった。

この辺りがUbuntuLinux Mintでは簡単で羨ましかったのだが、

fedyというソフトを使うことである程度は解決できるようだ。

http://satya164.github.io/fedy

fedyは手順の面倒な設定やインストールを簡単にするソフトのようで、

導入は次のようにすれば良いよう。

※fedy-installerはただのシェルスクリプトで、後で消して問題ない。

curl -o fedy-installer https://satya164.github.io/fedy/fedy-installer
chmod +x fedy-installer
sudo ./fedy-installer

Skypeインストールは次のようにする。

sudo fedy -e skype_linux

skype_linuxはタスク名前で、Flash場合はadobe_flashLight Tableの場合light_table、Sublime Text 2の場合sublime_text2といった具合。

GUI版のfedyがイケてない気はするけど、

とりあえずSkypeインストールできてよかった。

2015-04-07

curlの-cと-b

curlコマンドが非常に便利で、最近はよくお世話になっている。

しかし、-cと-bどちらがcookieの保存なのかcookieの送信なのかで混乱し、

何度か「bはbakeの略な気がするから多分…」といった勘違いミスを起こしてしまった。

※保存するのは-c(--cookie-jar)、送るのは-b(--cookie)

長いオプション名のほうが比較的混乱しにくいので今のところはそちらを使うようにしているが、

短いオプション名の由来が分かればそちらを使いたい…。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん