私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ【PHP】2chat開発スレ【2chを越える】
php スレッド一覧へ / php とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
authorization認証よく分からん
とりあえずはリクエストパラメーターでいいか…
とりあえずはリクエストパラメーターでいいか…
いや、別にOAuth2とか使わないんでしょ?
で、独自認証なんでしょ??そんだったら、
Authorizationヘッダのフォーマットを自由に決めていいんだって
(HTTPのAuthorizaitionヘッダの形式に違反しないかぎり)。
例えば、Authorization : nch {token}
とか
で、独自認証なんでしょ??そんだったら、
Authorizationヘッダのフォーマットを自由に決めていいんだって
(HTTPのAuthorizaitionヘッダの形式に違反しないかぎり)。
例えば、Authorization : nch {token}
とか
>>551見ると、Authorization ヘッダについて調べたのセクションに
Authorization: auth-scheme (token68 / auth-params)
ってなってんじゃん。この形式にしたがってフォーマット決めておけばOK。
例えばauth-schemeは「nch」ね(IANAにもちろん登録されてないスキームだけど)。
後はtoken68の形式か。
Authorization: auth-scheme (token68 / auth-params)
ってなってんじゃん。この形式にしたがってフォーマット決めておけばOK。
例えばauth-schemeは「nch」ね(IANAにもちろん登録されてないスキームだけど)。
後はtoken68の形式か。
なるほど。スキームは自由でいいのか
Authorization : nch (token_id) (token_key)みたいな感じで
Authorization : nch (token_id) (token_key)みたいな感じで
auth-scheme [ 1*SP ( token68 / #auth-param ) ]
厳密にはこうだから、パラメータ2つ渡したいなら
Authorization : nch id=(token_id), key=(token_key)
こんな感じかな。確か,区切りでいいはず。
厳密にはこうだから、パラメータ2つ渡したいなら
Authorization : nch id=(token_id), key=(token_key)
こんな感じかな。確か,区切りでいいはず。
それってどこに空白入れてもいいんだよね?
=の前後とか
解析難しそう
=の前後とか
解析難しそう
で、認証が必要なAPIに認証せずにリクエストしたら、
ステータスコード401のUnauthorizedでレスポンス返す。
で、レスポンスのヘッダにWWW-Authenticate : nch
って指定して、nchスキームでの認証が必要ですよって示すのが普通。
ステータスコード401のUnauthorizedでレスポンス返す。
で、レスポンスのヘッダにWWW-Authenticate : nch
って指定して、nchスキームでの認証が必要ですよって示すのが普通。
RFC 7235には
auth-param = token BWS "=" BWS ( token / quoted-string )
BWS=Bad White Spaceで仕様上は許可してるけど、推奨しないホワイトスペースだね。
auth-param = token BWS "=" BWS ( token / quoted-string )
BWS=Bad White Spaceで仕様上は許可してるけど、推奨しないホワイトスペースだね。
解析自体は難しくない。quoted-stringのを使わなければ。
まず、ヘッダ全体をスペースでSplitする(.NETならString.Split)で、
先頭がauth-scheme。で、今度は残り全体をまず「,」でSplitする。
でそれを今度は「=」でSplitして、終わり。
適宜前後のホワイトスペースをTrimする。
まず、ヘッダ全体をスペースでSplitする(.NETならString.Split)で、
先頭がauth-scheme。で、今度は残り全体をまず「,」でSplitする。
でそれを今度は「=」でSplitして、終わり。
適宜前後のホワイトスペースをTrimする。
>items[2].Split(',').Select(i => i.Trim());
は
items[1].Split(',').Select(i => i.Trim());
こうだった。
だから、君の仕様でquoted-stringを使わないように認証トークン生成して
仕様で決めてくれれば解析は楽。
は
items[1].Split(',').Select(i => i.Trim());
こうだった。
だから、君の仕様でquoted-stringを使わないように認証トークン生成して
仕様で決めてくれれば解析は楽。
思ったんだけどid=(id),key=(key)にするメリットって何?
省略可能なパラメーターがある訳ではないし(id),(key)の方が楽だと思う
仕様でそうなっているから?
省略可能なパラメーターがある訳ではないし(id),(key)の方が楽だと思う
仕様でそうなっているから?
まぁ、もちろん一番楽なのは、
Nch-ID : token_id
Nch-KEY : token_key
と独自ヘッダで分けてくれれば一番楽だね。
Nch-ID : token_id
Nch-KEY : token_key
と独自ヘッダで分けてくれれば一番楽だね。
名前被りがなければ自由にヘッダって作っていいんだよね
それならそうしようかな
それならそうしようかな
プッシュしました
了解。idとtokenに使う文字は注意してね。なんで使えるわけじゃないから。
仕様で確認してね。
仕様で確認してね。
>>572
idは数字のみ、tokenはbase64から=を除いたものだから多分大丈夫
idは数字のみ、tokenはbase64から=を除いたものだから多分大丈夫
エラー関係はCSVで外出しした方が管理楽かも
twitterの200台ステータスは200 OKしか使ってないみたい
これは分ける必要なさそう
これは分ける必要なさそう
いやいや、偉くないだろ。ユーザーにとっては、完成させれるか完成させれないかの
どっちかしない。開発者にとっては、完成させれなくても勉強になるけど。
だから、進んでても最終的に完成するかしないかが問題。
どっちかしない。開発者にとっては、完成させれなくても勉強になるけど。
だから、進んでても最終的に完成するかしないかが問題。
HTTPステータスコードってこんな感じ?
200 成功
401 認証が必要/認証エラー
403 リクエストの送りすぎ(書き込み間隔が短い)
404 見つからない(スレなど)
409 既に存在する(スクリーンネームなど)
421 リクエストがおかしい(パラメータが足りない、数値に変換出来ない、文字列が正規表現に一致しない、長すぎる)
500 鯖内部でエラー
200 成功
401 認証が必要/認証エラー
403 リクエストの送りすぎ(書き込み間隔が短い)
404 見つからない(スレなど)
409 既に存在する(スクリーンネームなど)
421 リクエストがおかしい(パラメータが足りない、数値に変換出来ない、文字列が正規表現に一致しない、長すぎる)
500 鯖内部でエラー
例えば、トピックIDを指定して取得するAPIで見つからなかったらエラーを返しているけど、
トピック検索APIで見つからなかったら成功+空の配列を返している
つまり単取得系と多取得系の違い
これってどっちもエラー返すべきだろうか…
トピック検索APIで見つからなかったら成功+空の配列を返している
つまり単取得系と多取得系の違い
これってどっちもエラー返すべきだろうか…
ワロタ。やっぱ動かしてないかww
昨日も書いたけど、すごい水平展開に開発していくな。
http://tools.ietf.org/html/rfc7231
には421のってないな。
まぁ、そんな感じでいいんじゃないかな。
細かいところはAPIによってもマチマチだし。
昨日も書いたけど、すごい水平展開に開発していくな。
http://tools.ietf.org/html/rfc7231
には421のってないな。
まぁ、そんな感じでいいんじゃないかな。
細かいところはAPIによってもマチマチだし。
>>581
それでいいと思う。検索の方はエラーじゃなくていいと思う。
それでいいと思う。検索の方はエラーじゃなくていいと思う。
ウィキペディア見てた
421 Misdirected Request (RFC 7540)
誤ったリクエスト。
421 Misdirected Request (RFC 7540)
誤ったリクエスト。
とりあえずエラーコードは連番でしてみる
500エラーはエラーコード-1だけでいいか
詳細教えたら危険だろうし
詳細教えたら危険だろうし
というか、マジで動かす方を優先した方がいい。
でないと、また、大幅な手戻り発生しそう。
クラスの依存関係で無理って言ったけど、そんなの当たり前。
だから、そこらへんは適当に動くようにつくればいいだけ。後で修正すればいいんだから。
>>544の人もアドバイスしてくれてるのに。
でないと、また、大幅な手戻り発生しそう。
クラスの依存関係で無理って言ったけど、そんなの当たり前。
だから、そこらへんは適当に動くようにつくればいいだけ。後で修正すればいいんだから。
>>544の人もアドバイスしてくれてるのに。
とりあえず動かした方がいいのか
なら適当にAPI作って動かしてみる
なら適当にAPI作って動かしてみる
俺もPHPの勉強し始めてるっていって、この前ASP.NET Coreをやりだしてるっていったけど、
君みたいなやり方してないぞww
初めての作業で全体像見えないまま、クラス設計なんてしようがないし。
だから、とりあえず、1,2つだけモデルクラスを作って、それで次はすぐにWeb APIの方作って、
実際にブラウザからアクセスさせてる。
それで、作り方に問題なさそうって確認してから、おおざっぱに全体の設計を
把握してから残りモデルクラスの作業に取り掛かってる。
君みたいなやり方してないぞww
初めての作業で全体像見えないまま、クラス設計なんてしようがないし。
だから、とりあえず、1,2つだけモデルクラスを作って、それで次はすぐにWeb APIの方作って、
実際にブラウザからアクセスさせてる。
それで、作り方に問題なさそうって確認してから、おおざっぱに全体の設計を
把握してから残りモデルクラスの作業に取り掛かってる。
PHPerだけどサーバサイド5日くらいで終わりそうじゃね?
ぼくのかんがえたさいこうの設計目指さなければ
ぼくのかんがえたさいこうの設計目指さなければ
まぁ、元々機能少ないからそんぐらいだろうね。データベースのテーブルも
5,6ぐらいしかないし。
5,6ぐらいしかないし。
ただ、俺はPHPで開発環境が悪いのか、コード補完とかあんま効かなくて、
タイプミスとかでエラー、メソッド名もまだ覚えてないから補完したいのにで
出なくていちいちブラウザで調べたりしてブチキレで。ASP.NET Coreの方に移行中だけど。
タイプミスとかでエラー、メソッド名もまだ覚えてないから補完したいのにで
出なくていちいちブラウザで調べたりしてブチキレで。ASP.NET Coreの方に移行中だけど。
5日ってそんな物なのか?
もしかしてここって職業プログラマ多い?
もしかしてここって職業プログラマ多い?
君は、HTTPの基本みたいな事だってわかってなかったし新しい事を覚える時間が
かかるんだからしょうがないよ。
でも、なれればテーブル数も5,6ぐらいで小機能だし、5日ぐらいで実装できると思う。
俺はまだサーバーサイドは素人だから慣れが必要だけど。
でも、クライアントサイドやってきた経験から言うと、慣れれば機能的には5日くらいあれば実装できるとは思ってた。
サービスの仕様とか考える時間とかは別問題だから抜かしてね。
単純に実装する時間だけの話ね。
かかるんだからしょうがないよ。
でも、なれればテーブル数も5,6ぐらいで小機能だし、5日ぐらいで実装できると思う。
俺はまだサーバーサイドは素人だから慣れが必要だけど。
でも、クライアントサイドやってきた経験から言うと、慣れれば機能的には5日くらいあれば実装できるとは思ってた。
サービスの仕様とか考える時間とかは別問題だから抜かしてね。
単純に実装する時間だけの話ね。
これで小機能って凄い
俺の中では今まで作ったWEBアプリで一番大きいのに…
俺の中では今まで作ったWEBアプリで一番大きいのに…
とりあえずコンパイル通ったのでweb.xml作っていきます
業務とかに比べると全然ちいさいよ。
業務だとテーブルだけでも何十、何百って数あるんだから。
で、それらのテーブルを複数結合したり、バッチで何十のテーブルを見て更新かけたり。
だからテーブル数5,6って学生の宿題用(テーブル数2,3?)に毛が生えたぐらいの規模だと。
2chだってもともと小機能なんだし。ただ、小機能とはいえユーザー数は
圧倒的だから。そこらへんはまた単純に作るだけじゃなく別のノウハウが必要だと思う。
業務だとテーブルだけでも何十、何百って数あるんだから。
で、それらのテーブルを複数結合したり、バッチで何十のテーブルを見て更新かけたり。
だからテーブル数5,6って学生の宿題用(テーブル数2,3?)に毛が生えたぐらいの規模だと。
2chだってもともと小機能なんだし。ただ、小機能とはいえユーザー数は
圧倒的だから。そこらへんはまた単純に作るだけじゃなく別のノウハウが必要だと思う。
>>599
テーブルが何百って…そんなにあるのか
2chは単純だからな。ユーザーが多い以外に良い所がない気もするけど、掲示板だとユーザーの数が最大のメリットになるし
専門学校とか大学の工業科ってこういうの作ったりするの?こういう系の仕事するなら工業科進んだ方がいいかな
テーブルが何百って…そんなにあるのか
2chは単純だからな。ユーザーが多い以外に良い所がない気もするけど、掲示板だとユーザーの数が最大のメリットになるし
専門学校とか大学の工業科ってこういうの作ったりするの?こういう系の仕事するなら工業科進んだ方がいいかな
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php スレッド一覧へ
みんなの評価 : 類似してるかもしれないスレッド
- 【PHP】 Smarty 隔離スレ 【テンプレート】 (1001) - [46%] - 2010/3/28 11:16 ○
- 【PHP】Laravel【フレームワーク】 (887) - [44%] - 2019/4/23 21:00
- 【PHP】Ethna part.2【国産フレームワーク】 (315) - [36%] - 2019/5/9 7:45 ○
- 【PHP】PHPフレームワーク総合スレ14 (1001) - [36%] - 2010/12/11 10:32
- 【PHP】PHPフレームワーク総合スレ15 (989) - [36%] - 2013/9/27 6:00 △
トップメニューへ / →のくす牧場書庫について