不具合とは総じて変な物である。

不具合は原因が無ければ発生しない。

不具合が無い様、あれこれと柵を巡らせているのにもかかわらず、何故か発生し、原因が分からない。


しかし、ちょっとした偶然で見付かることが多く、不具合の原因とは、発生した不具合とは本質的に異なることが多い。


先日、同じファイル名があってアップ出来ないという問題が発生していたと書きましたが、ホントくだらない原因でした。

そもそも、その場所は、ファイルabcdefg.hijをabcdefg.hijklにして、ダウンロードし、abcdefg.hijをabcdefg.hijmnに変更して、abcdefg.hijklをabcdefg.hijにして、abcdefg.hijmnを削除するという方法をとっていました。

これには、何ら問題は無いはずでしたが、今甦るMS-DOSの死産

ファイル名が被らないように拡張子の後ろに文字を追加したabcdefg.hijklはabcde~1.hijという別ファイル名をも持っていました。

abcdefgがabcde~1で合ったために、本来abcde~1.hijは存在しないにもかかわらず、８．３ファイル名としては存在するファイル名として処理されました。

これらの問題は、色々と考えてみましたが、対処出来る度合いを超えています。

例えば、aaaaaa~1.b
というファイルをダウンロードしたい場合、
aaaaaaaaa.bというファイルが既に存在しaaaaaa~1.bという8.3ファイル名が割り当てられていた場合、
当然上書きしてしまいますし、aaaaaa~1.bというファイル名でダウンロードしたとしても、その結果のファイルはaaaaaaaaa.bとなってしまいます。
aaaaaa~1.bにはなりません。

これを何とかするには、aaaaaaaaa.bを全然違うファイル名に変更するか、短くして、８．３形式を外します。
その後、aaaaaa~1.bをダウンロード（作成）します。
その後、aaaaaaaaa.bだった物をaaaaaaaaa.bへ戻します。
するとaaaaaa~2.b等の新しい８．３形式が割り当てられます。

短くする方法は衝突する可能性がありますので、ファイル名を作成するのが大変です、しかし８．３形式はファイル名の前方が残るので、前の方に余分な文字列を追加する分には簡単に違う８．３ファイル名にすることが出来ます。

それにしても、不具合の原因がMS-DOSに由来するとは思っても見ませんでした。

あとは何とかして、１００Ｍ以上のファイルを送れる様にしたいですね〜

先日書いたここの予想と、実際のアニメの進捗は、合っている部分もあれば、間違っている部分が大半のような感じですが、

それで居ても、大筋は余り間違えていなかったように感じます。



１２話まで見てない人は、見てからの方が良いですよ？？

１１話までのネタバレを含んでいます☆




神樹様がどう言う存在なのかは、軽く本編で触れられていましたが・・・

まさか、四国以外滅んでいるとは思いもしませんでした。

贄システムは、そのまんまの贄のようで、前勇者との欠損部分は特に関係が無いみたいですけど

勇者システムを乗り越えて勇者として完成するかと思っていた、その辺りのお話は、
東郷さんの機転により、あっさり滅亡か、勇者かの２択になってしまって、わっし〜さすが！

どっちが原作か微妙に判らないけど、わっし〜の話が本になっていますよね。

初めは、どんだけパクった話かと思っていたんですが、そうですか、東郷さんの話ですか。


初めてこの作品を見たときは、良く有る感じの学生が勇者やってる程度かと思っていたんだけど、５話で敵全滅とか、ありきたりでは無いと思いました。

その時点では、話がどっち方面に進むのかが不透明だったので円盤買うかちょっと悩んだんですけどね？
ここ（１２話）まで来たら、話の最後がどう転ぼうとも買うことにしまして、取りあえず注文したんですが・・・・
１２／２５入荷だそうです。

売り切れか〜、

限定版のゲームには特にこだわってないけど、それ以外の仕様が違ったらヤダな？とか思っては居ます。


他、異能バトルは日常系のなかでとか、買おうかなとか？思わなくも無いけど、
原作の方もちょろっと最新刊が途中で放置になっているけど、
急にお金が必要になって貯めることになったので、円盤沢山買っていられないので、中古が安くなってセット売りになってから買うかな？って感じ？


それはそれとして、あれだけの小さな空間では、
１．携帯は作れない。
　レアメタルとか必要ですから、日本だけでは作れません。
２．それ以前の環境平衡
　エコシステムとしての循環が成り立たないサイズ
３．襲撃がとても頻繁
　例え勇者システムが有っても、そう遠くない未来にいずれ全員が神樹様の贄になって終了
４．壁の向こう
　実は、壁が撃退時のみ有るんだと思っていたんだけど、常にあるのが笑った。
　世界の果てが見えるってどう考えてもおかしい。
　閉鎖後に生まれた人はそうかもしれないけど、閉鎖前から生きている人って居ないのかな？情報統制とかどうしたんだろう？

ある日奴らがやってきた→神様頑張った→箱庭が残った

まぁ、１日２日くらいは世界中が戦ったかもしれないけど、その僅かの間に、人的、経済的、技術的な資源を集めること何て不可能ですから、たまたまあそこだけ残ったのでしょうね？

あの壁の中ってどんなに長く保っても１００年かそこらが限界でしょ？

やっぱり、神樹様じゃ無い柱が必要じゃ無いかな？それで、バーテックスの奴らを根本的に解決しないと、今日明日を生きるだけになっちゃうんじゃ無いかと思う。

バーテックスそのものに対する情報があたしには無いから何とも言えないんだけど

何らかの条件を満たせば、居なくなるのか、それとも全滅させないとイケないのか、その辺りがさっぱり分からないわね。


ああいうのを見ると、地球って、やっぱりこのサイズ無いと生物は生きられないよね？　とか思うのです。

具合が正常では無い状態。それを不具合と言います。

プログラムを作る上で、不具合というのは基本的に無い様に作っています。


今のプログラムは関数型が主だったもので、

ａというパラメータを入れるとそれを計算した結果のＡを出力します。

これは非常に固定的な物で、いつ、何処で、どんな風に、実行しようとも変わりません。


ですから、不具合が発生するはずが無いのです。

ゲームの場合も、アプリケーションでも、それらは変わりません。


ただ、パラメータが一つでは無く複数有るだけの話です。

パラメータが複数有ると、パラーメータの一つがちょこっと変わっただけで、画面上では大きく違う動作を行うことがあります。

それでも、全てのパラメータを正しく、順番通り、処理すれば不具合など発生しないのです。

それが、プログラムの利点で有り、プログラムの限界でもあります。


でも、それが故に、本来不具合は発生しないのです。
それでも、不具合が起きる。ユーザーから苦情が来る。

制作者は死にものぐるいで不具合の原因を突き止め、それを修正する。


大抵は、「全てのパラメータを正しく順番通りに処理」していないから起きます。


プログラムの作成は大抵、半年〜数年掛けます。


また、商品の寿命が長ければ、機能強化やらなにやらアップデートを繰り返すことになります。


作り始めた当初と、作り込んでいく先でプログラムに　新型と旧型が混ざることになります。


新型のプログラムというのは、これまで有った不具合を但し、新しく追加した機能のために様々なパラメータが増えたりしています。

しかし、古い方にはそう言った物が一切ありません。

大抵は、追加した機能により修正した部分よりも、何も変更しても居ない部分で発生することが多かったりもします。


でも、それ以上に問題なのは、連携です。

プログラム１とプログラム２の間で、取り決められている条件の物でパラーメータを遣り取りし、お互いに補完し合いながら動作することがあります。

しかし、プログラム１はアップデートしていないのに、プログラム２だけアップデートするなどで、取り決められた当初とは違うパラメータの遣り取りが発生する場合があります。

本来であれば、プログラム１側で、定められた範囲外のパラメータに対しては、プログラム２にエラーを返したり。

予め、プログラム２と連携するときに相手のバージョンを確認するなどの対応があれば、不具合が発生しないのですが・・・

相手側が一切情報を公開していない場合はどうなるのでしょうか？？


ようするに、OneDriveの事です。


REST APIはあれもこれも色々と出来ると言っていますが。実際に始めると、色々と出来ないことが多いのが分かります。

じつはブラウザを利用したり、MS純正のOneDriveアプリを利用したりすると、ファイルの更新日が正しく反映されていたり、１００Ｍ以上のファイルが送れたりします。

REST APIにはファイルが大きい場合は分割送信が出来ると書いてあり、 HTTP1.1のページへの誘導を行って、Range パラメータを利用することで、大きいファイルの送信が可能と言っていますが・・・、

multipart/byteranges
とか
Range
の話ですが、どれもこれも、サーバーのレスポンスの話として書いてあって、クライアントからの送信時に使えるかは分かりません。

いずれ試してみますが、WebClientではサポートしていないので、自分でバイナリデータを作ってやってみるしか有りません。

ようするに、OneDriveと、同期を取る方法として、現在公開されている範囲のRESTでは不完全なわけです。


「１００Ｍ以上のファイルがあると同期が正常に取れない。」　これが一つ目の不具合です。


しかも、それだけじゃ有りません。


今作っているソフトは、OneDriveとクライアントで同期を取るだけで無く、一方的にアップロードすることや、一方的にダウンロードすることも出来ます。

ようするに、相互に最新の物を優先する方法と、　クライアントにあるのを絶対のマスターとすること、逆に鯖にある物をマスターとすることが可能になっています。

で、OneDriveのREST手引きには、「自動的にアップロードする様なアプリの作成は控えるべき」と書かれていましたが、ならば、一方的なダウンロードには特に問題が無いと言うことに成ります。


先述の通り、ファイルの更新日などが正常に反映されない、させる方法が公開されていないREST APIで更新するくらいなら、ブラウザでアップロードする方が楽かもしれません。

で、実験してみると、これがまぁ、不具合が出るのです。


サイズが100M以上有るから？

それも違います。
先日５００Ｍ以上のファイルをなんの問題なくダウンロード出来ました。

じゃぁ、何か？


これまで、テストと称してダウンロードを始めたのですから、初めてのダウンロードです。

当然です。

ディレクトリも全部自動作成です。
それにもかかわらず、ダウンロード時にエラーが出るのです。

エラーを詳細に追ってみると、あり得ない場所であり得ないエラーが出ていたのです。

先ほどの通り、初ダウンロードです。
フォルダ自体も、事前に作っています。

しかし、根本的なところとして、事前にファイルがあった場合、それと差し替える機能を作ってあります。

そして、その差し替え機能が動作していました。

ダウンロードは、そもそも異なる名前でする用になっています。
違うファイル名でダウンロード、現在のファイルを別名に変更、新しいファイルを正しいファイル名に変更、古いファイルを削除、

そう言った手順です。

エラー処理も多重に入れており、いざというときは、旧ファイルで復旧出来るようにしてあります。
まず１つめの問題。
何故、ファイルがあったか。

考えられることは一つしかありません。２回ダウンロードしたからです。

ファイルリストに何らかの影響で、同名のファイルが二つあったのです。
ファイルリストはOneDriveに提出して貰っているので、履歴か何かの影響で複数合ったのでしょう。
２つ目の問題。
先ほどの通り、置き換えるようにプログラムを作っています。
例え２回ダウンロードしたとしても、後からダウンロードしたのが優先されるだけでエラーが出るはずがありません。

しかし、フォルダを見てみると、ファイルがありません。

ファイルは単純に、moveで順番に更新しているだけなので、消えるはずがありません。

しかも、ダウンロードしたファイルがありません。既存のファイルを大体のファイル名に変更した物はあるのに、ダウンロードしたファイルがありません。

一応、ダウンロード時にエラーが出た場合は、エラー処理を行いますので、それはそれで問題はありません。

ダウンロードを完了したのに、ダウンロードしたファイルが無い。

それが、今回の不具合です。


では、原因は何故でしょうか？

もちろん、２回同じファイルをダウンロードしようとしたこともあるでしょうが、もう一つが
１回目のダウンロードです。

１回目は別名でダウンロードしますが、特別な名称ではありません。
単に適当な文字列を追加しただけで、ユニークではありません。

別名で保存−＞正式なファイル名で保存。
２回目の実行時ですが、先に別名の方を削除するプログラムを先頭に入れています。
そして、ファイルがある場合はエラーで返すことになっていますので、ここまでは問題ありませんし、別名でダウンロードした後、既存のファイルがある側の処理にうつっています。

ここで、既存のファイルの代替への変更が完了しています。
ここまでは実行されているのでエラーはこの後と言うことに成ります。

ダウンロードしたファイルを正しいファイル名へ変更ですが、ここでファイルが無いのでエラーになっています。

考えられるのは、ダウンロードのエラーですが、エラーその物は発生していないし、もう一つで言えば、ダウンロードは正常に終了したのに、ファイルは作られなかった。

ですね。


これらのことより
１．同じファイル名があったら、どちらをダウンロードするか判断する。
２．例外が発生しなくてもダウンロードが失敗していないか確認する必要がある。

ですね？
２．に付いては、事前のファイル情報を受信したときに、ファイルサイズとか調べておかないと分かりませんね？　あと、ファイルの時間とかも更新日付で修正した方が良いかもしれません。


ある程度連続でダウンロードするとファイルの受信が出来ない。これが二つ目の不具合です。

ちなみに、ある程度は結構なファイル数です。
また、詳細なテストのために暫く放置していたためか、それ以降のファイルが全く受信出来なくなっていました。

土日にしか書いてないので、当たり前なんですが？
静波に履かせるパンツを何にするか考えた結果、その辺で売っている可愛いのを片っ端から買い集めて検討しました(笑)

レースでフリフリなのも可愛いですが、無地なのや、チェック、縞模様も好きだし、
結構迷う。

それはそれとして、パンツを見る上で、一番可愛いポーズと言うのはほぼ決まりました。

「パンツの見える人物が可愛い」ではなくね

パンツはそもそも前と後ろと、二通りの見られ方が想定されていると思うのです。

パンチラやら、脱がされている最中とか、スカートなら、めくられている時もかな？

前からなら、アソコを中心とした、V字、ボクサータイプ？なら、M字？
まーV字と言っても下は尖っていないので何字でしょね？

アソコの緩やかなカーブ、ソコへ向けての多数の引っ張りジワ、模様の歪み、真ん中に筋が入っていると、陰唇のプックリ感や柔らかさが見て取れるわね☆

シンプルな無地を書き込んでも良いし、チェックを歪ませても良いわね☆

ボクサータイプだと、足の付け根への引っ張りジワがさらに増え、アソコへの、集中゛力゛か、上がるわ？
さらには腿の部分が、程よい横じわで内腿の詳細なディテールと、パンツと太股の境目がむっちり感を出す。

前からはアソコの可愛さが余す事無く表現できるけど、ただのエロよね(笑)

どんだけ可愛くても、履いている娘のエロさが、引き立つだけ。

前からじゃパンツの可愛さを表現しきれないわ？


続きは、次号　続きです・・・・


なので、Ｔバックは論外なのです。

Ｔバックに対して、フルバックとか言うらしいのですが？

お尻を柔らかく包み込む生地、お尻に合わせて変幻自在な伸縮を行う。


バックプリントがあるもの、生地自体に柄があるものとか色々とありますが、この場合、無地はちょっぴり残念感が大きいです。


後ろ側における最大のポイントは、お尻その物が割れていることに起因する、伸びと緩みです。
また、下部は・・・クロッチの前側はアソコを柔らかく包み込む反面、後ろ側はお尻の割れ目に挟まれます。

この割れ目に沿って進みながらも、フルバック所以の生地が左右に引っ張られ、すぐに一番引っ張られる場所に到達します。

クロッチの後ろ部分で、お尻の割れ目を表現しながらも、生地が伸びて割れ目を隠しているところが、必用以上にエロくしない重要なポイントで

ウエストに掛けて細くなることで、伸びていた生地が緩み、場合によっては、ゴムで締めている分ウェスト直下が緩んでいる物もあります。

でも、柄的に伸びも余ったりもせず、ぴったり肌に吸い付くくらいが一番だと思います。


お尻の特徴を全体で表現しながらもお尻そのままの形状を表すこと無く、パンツの伸縮にて柄を歪ませることでその役目を全うしていることを知らしめる。

お尻じゃないわ！、パンツよ！

お尻かくして、パンツ隠さず！


パンツが見えることで可愛さがが最大になる。パンツの可愛さが最も強調されるんだと思います。


ちなみに、上記を満たす光景として

膝上くらいの高さから、スカートが翻って、クロッチの後部、ちょっとのお尻の割れ目及びバックの大半が見えている状態（上半身は振り返って恥ずかしがっているような感じがお勧め）が最もステキかと思います。

そういえば、クロッチとの境目を2本線引いている人が多いけど、
一つは、前側の布とクロッチの布との境目であって、二本目はあるとしても、折り返しを縫い止めるための補強で、ないものの方が大半だと思うの。

昔はいていたお子様パンツには、破けにくいように縫ってある物が多いけど、最近のパンツはほぼ縫っていないわ？

あと、クロッチの部分の当て布を、外側に縫い付けている３パーツタイプもそれなりの量有る事が分かったけど、
あたしとしては、クロッチの部分を当て布も、外側も分離している４パーツタイプのパンツがお勧め。

これにより、クロッチの縫い目が、前側と後ろ側に２ヶ所２本ずつ４本入る（注：前述の通り１本ずつで２本のパンツが最近増えています。）のと、
前の生地と後ろの生地を縫っている部分が１ヶ所でクロッチの縫い目が真ん中辺り（正中では無い）に１ヶ所２本だけ有るタイプが有るわけです。

１ヶ所タイプの物は、補強のために折り返してから縫ってあるので、ほぼ必ず２本ですね？


それはそれとして、最近のパンツは、クロッチの当て布（内側の方）がとても短いのが多い。
アソコと、後ろと２ヶ所をくまなく覆うには、それなりの長さ１０ｃｍ以上は居ると思うんだけど、短いのは５ｃｍも無い物もあるわ？

あたしの体形が間違っていなければ、ほぼ真下。
アソコの口の下にだけ有るわね？

日常的な状態での、保護とか、防衛とか、目隠しとか、衛生とか　そういう事を考慮したものでは無いと思うわ？

多分、勝負パンツね？

脱がされるまで耐えられれば良いとか、そういう感じ？

お汁の多いあたしの場合は、一瞬でスケスケになると思うけど。


パンツ談

OneDriveとの同期を取るためのプログラムが大分良い感じになってきました。

OneDriveとのアクセスの方法は先日までの初級編〜上級編で一通り、あれこれが出来る様になったのは良いとして・・・

それはそれで、色々と問題が山積みになりましたよ。

ローカルの日付とOneDrive上の日付。

日付は更新日とか作成日になるけど、当然、クライアント側の更新日は、実際に更新した日。
鯖上の更新日は、あくまでアップロードした日付。

だから、鯖上のファイルが最新と勘違いして逆コピーを始めてしまう。
まぁ、同じファイルだけどね

そうすると、ローカル上の更新日が変更されてファイルの更新日が変わってしまう。

さっき、逆コピーって書いたけど、
複数箇所で同期を取るのであれば、新しく追加されたファイルを追加指定場所へダウンロードする必要がある。

それはそれとして、あくまでマスターはローカルにある何処かの場合、そう言った機能は不要になる。
複数箇所で同期したい物と、あくまでローカルが元で、それをバックアップ目的で上げるモノは大いに違う。

逆に余分なファイルは消さないといけなくなる。

コピーする目的により、複数のパターンが必要になり、オプションが沢山増えて、それに伴って必要なデータもかなり変わりました。

自動的に同期をするのであれば、定期的にファイルの更新が無いか調べなければならないし、
それってば結局は、通信量の増大に辺り、
鯖側のディレクトリ更新時におけるファイル一覧データの差異がとても気になるようになってきた。

初めは適当に、順にたどり治せば良いかと思っていたけど、深くなればなるほど、追うのが遅くなる。
影響が出る範囲を調べ上げて、その上で変更のある範囲だけ、ディレクトリ情報を更新して、ディレクトリの移動が遅くならないようにもしました。


とにかく、通信の削減と、検出の強化、

結局、コメントの所にXMLを埋め込むことにしましたよ？

今は未だ処理していないけど、元々有るコメントから、XMLだけ抜き出して、それだけ更新するように処理を入れないとダメだし、

周期的に実行する機能も作らないとダメだし、
色々と通信待ちをする場所が増えた関係で、ユーザーがいつ中断するか分からないので、中断に関連する処理をそこら中に入れなければ行けなくなったし、ほんと大変。

ローカル上で行っていたときのソースコードの倍を超えている感じですよ、

とても大変です。

でも、もうちょっとですね〜

頑張らないと！

敵をあっさり全滅させたと思ったらその後の話の方が長いパターンの「結城友奈は勇者である」

神樹様？（字が分からないけどまぁ何でも良いかな？）を中心に世界が構築されている日本？のお話みたいだけど、

この話のキモは、勇者システムを利用した次世代神樹様？の作成に有るんじゃ無いかと思う。


ちなみ、

これまでの話を見た上での、あたしの勝手な想像について熱く語ります。

原作があってそれを知っているのか、ステマか、東郷さんの精霊の数と、満開後の精霊の数についてあれこれ書いてあったことが有りましたが、そんなことよりも

先代勇者の残っている部分がとても気になりました。
部長の左目、妹の喉、友奈の口、東郷の左耳。

なんか一緒じゃない？

手足は、まるで何も無いかのように服がぺったんこで・・・ねぇ


勇者システムというのは、候補者4人（5人）の中から時代の神樹様？に最も適した人を選別するための物で、あれらは、実は敵ですら無いかもしれない。

候補の人達の優れた部分を一つずつ間引いて、現代の神樹様？（先代勇者）に付与して言っている感じがする。

その後、完成体として神樹様になるのか、現代の勇者と神樹役を交替するのか、分からないけど

数年おきに神樹役を交替し続けている感じがするわね

これが、前々回に先代勇者が出てきた時点で思った、今後のストーリー

前回は、東郷さんによる、先代勇者が言っていた「勇者は死ねない」を実証した、なかなか怖い感じの話と、部長がぶち切れる感じの話で、進展は全くなかった・・・・

あ〜、友奈がゲージ満タンになりましたね、

そろそろ敵と称する物体が現れて、満開を強要するのでしょうか？


あたしの考えが正しければ、夕奈は次代の筆頭と言うことに成りますね。

それで神樹様に成ってしまうのか？　　勇者として、神樹システムを根本から破壊するのか？

タイトルを穿った見方をしないのであれば、後者がエンディングへの道かと思います。


まぁ、始まったときに期待した内容とはまるっきり違う感じのお話で円盤買うかちょっと迷っているんですけどね？

良く出来ているのに、内容が想定外過ぎて、もう一度見たいと思うのかどうか、微妙。

まぁ、１〜５話はけっこう何度も見ているけどね

さて、前回までに、一通りOneDriveでのファイルへのアクセスの仕方をだらだらと書きましたが、ここから先は、一応上級編です。

何が上級なのかというと、できることがすごくなるのではなく、何気なくやると、危険なことです。


前回の最後にちょろっと書きましたが、今回はリフレッシュトークンを取得して、OneDriveへの常時接続を行います。

先日の例にも書いてありますが、OneDriveで発行するアクセストークンの有効時間は1時間です。


ログイン時に送られてくるJSONに

<expires_in type="number">3600</expires_in>（XML版）

と書いてあるかと思います

なので、1時間おきにアクセストークンの更新が必要なのですが、前回までのResponseType=tokenでは、wl.offline_accessを設定してもリフレッシュトークンは貰えません。

たぶん、貰えません。

リフレッシュトークンを貰うには、以下の方法を行う必要があります。


ResponseTypeをcodeにします。

すると　-　で繋いだ認証コードが貰えます。

このコードを使ってトークンの要求を行います。

また、これまでと違いClientSecretが必要になったりします。


ここで、重要なことを一つ、

リフレッシュトークンは時間切れになった場合に、アクセストークンを更新するために使います。

リフレッシュトークン　と　ClientSecret　がバレてしまうと、だれでも、どこからでもトークンの更新が出来てしまい、アクセスし放題になってしまいます。

リフレッシュトークンの保存場所にはご注意ください。

同様に、ClientSecretも出来る限りバレない方が良いです。

プログラムに埋め込んで、テキストとして保存しておくのは、危険な感じがします。


ＰＣの所有者が自分のOneDriveに対して何をやっても良いのですが、ウイルス等に感染して、ＰＣがダメになるだけで無く、クラウドのデータまで全て弄られてしまっては大変ですからね？


まぁ、そんな感じで、あたしが作成中のプログラムは、
System.Security.Cryptographyを使って、暗号化してから保存してあります。

まぁ、そう言う意味では暗号用のコードもプログラムに保存してあるって意味では、それも意味が無いと言うことに成ってしまいます。


で、有れば、起動時にユーザーに手入力させるしか無くなるので、それはそれで面倒な感じまします。

この辺りは、ユーザーの利便性とのトレードオフになります。


では早速新しい方法で接続してみましょう。


まず、動作手順をざっと紹介します。

１．リフレッシュトークンがあれば、再接続を試す。新しいトークンが貰えれば４へ
２．Codeでサインインを行う
３．認証コードでアクセストークンの請求を行う
４．リフレッシュトークンを保存する。
５．以下以前同様

注）動作中も、1時間経つ前に、リフレッシュトークンを利用してアクセストークンを更新し続ける必要があります。


実際の送信コード（かなり省略）

まず、リフレッシュトークンを利用して新しいアクセストークンを貰う方法ですが、

String sRes = "https://login.live.com/oauth20_token.srf"
+ "?client_id=" + ClientID
+ "&redirect_uri=" + RedirectURL
+ "&client_secret=" + ClientSecret
+ "&refresh_token=" + sRefresh
+ "&grant_type=refresh_token";

これを以前同様WebClientで送信すれば、リフレッシュトークンが有効であれば、これでJSONが帰ってきます。


JSONをXMLにしたのがこれ
<root type="object">
<token_type type="string">bearer</token_type>
<expires_in type="number">3600</expires_in>
<scope type="string">wl.skydrive_update wl.offline_access wl.signin wl.skydrive</scope>
<access_token type="string">　　　　　　</access_token>
<refresh_token type="string">　　　　　　　</refresh_token>
<authentication_token type="string">　　　　</authentication_token>
<user_id type="string">　　　　　</user_id>
</root>

refresh_tokenはさっさと暗号化して何処か別の所に保存して、生データはメモリ上からは消してしまいましょう。


では、リフレッシュトークンが無かったり、間違っていたり、もしかしたら時間が経ちすぎてリフレッシュトークンが無効になっていた場合はどうするかというと、

上の２．の用に普通にサインインを行います。

細かいところは以前のを参照、
ただし、&response_type=codeの必要があります。


さて、これで、問題なくサインインは出来るので、アクセストークンの様にGetのインラインで認証コードが帰ってきているので、これを取得しましょう。

以前のようなFragmentではなく ?で着いてくるのでe.Url.Queryで認証コードを取得しましょう。


次３番目　トークンの取得

アクセストークン、リフレッシュトークンの取得は上記のアクセストークンの更新同様に
https://login.live.com/oauth20_token.srf
に対して要求をしますが、
若干異なりまして、POSTする必要があります。
これまで、FormのデータをWebClientでPOSTすることはありませんでしたので、その方法を書きます。

まず、
パラメータはSystem.Collections.Specialized.NameValueCollectionに入れる必要があります。
これは、普通に宣言して、

System.Collections.Specialized.NameValueCollection nvcData = new System.Collections.Specialized.NameValueCollection();
nvcData.Add("client_id", ClientID);
nvcData.Add("redirect_uri", RedirectURL);
nvcData.Add("client_secret", ClientSecret);
nvcData.Add("code", AuthCode);
nvcData.Add("grant_type", "authorization_code");
wc.Headers["Content-Type"] = "application/x-www-form-urlencoded";
bRecivedata = wc.UploadValues("https://login.live.com/oauth20_token.srf", "POST", nvcData);

これで、トークンが取得出来ます。

トークンの形式は上のリフレッシュの時と同じ

リフレッシュトークンは、1時間経過してアクセストークンの有効期限が切れるまで必要ないので何処かに大事にしまっておいてください。

以下は、これまで同様アクセストークンを使ってアクセスすればＯＫです。

これで、OneDriveのオリジナルクライアントが作れますね☆

Windows7までの全てダウンロードしないと同期が取れなかったり、
Windows8の様にMSアカウントでサインインしないとOneDriveが使えなかったりとか
そう言った問題からも解消されますし、
別のディレクトリ、別のドライブ、別のＰＣに入っている、それぞれのディレクトリだけを個別に同期を取ったりすることも出来る様になります。

まぁ、あたしが目指しているのはこれです。

サーバーに入っているデータをバックアップする、
ＰＣ１に入っているデータをバックアップする。
ＰＣ２に入っているデータをバックアップする。

これって、全ファイル同期だと、結局全部のＰＣに全部のデータが入るだけですし、意味が無いですよね。

ソフトが出来たら、そのうちVectorに上げます。