アカウント名:
パスワード:
逆にレストラン側の予約システムを作る側としては、きっとbotによる予約は阻止したくなるかも。CAPTCHAを入れるとか。
個人的には人間でも読めないような難しすぎるCAPTCHAはイライラするのでダメだが、レストランの予約システム程度ならば簡易的なものでも十分だろう。
レストラン(のシステムを管理している担当)にとっては気持ちが悪いアクセスだし、システム障害に結びつく可能性もある。
キャンセル待ち予約機能を付ければbotのターゲットにならない気がします。(たぶん有料機能で
つーか、予約システムといっても受付はメールなのだから、受け付ける側が「botしね」と思うなら、そのアドレスの自動受付拒否して、拒否メールでも返信すればいいよね。ボール(bot予約を是とするか)はレストラン側にあって、サービス不能になるほどの頻度でアクセスしない限り、法的はもちろんマナー的にもどうこういう問題ではない。
>予約が実質的に不可能になっちゃいますし。
店側は常に満席だから文句はない。
単に予約の内容がまちがってたのでキャンセルして再登録しただけだったりして
https://gist.github.com/diogomonica/6076911 [github.com]
ソース見る限りWebフォーム登録ですね。
脆弱性スキャンや不正侵入を試みるアクセスにも見えて気持ち悪いよね。
単独で細々としてるならまだ良いが、複数のbotが頻繁に行うようになるとサーバの負荷も高まるし、リソース不足で障害になる可能性もあるよね。岡崎市立図書館は警察に通報して逮捕させた点が批判されたけど、サイト運営側が変なアクセスから防御して健全性を維持しようとするのはいたって正しい行為だよ。
そんなこといちいち書かなくてもわかりそうなものでしょうけど、上から目線で質問して偉そうにする人っているのよね。
横からだけど、システム運用も何もしたことがない人が、自分の無知をさらけ出しながら絡んでるようにしか見えないから、もう止めた方が良いと思うよ。
MDISの人?
システム運用してれば毎日のように明らかに不正アクセス狙いのログがあるんだからボットが予約のチェックに来るぐらい別に気持ち悪いことではないよ。クローラだって普通にあさりに来るし。いまどきシステム運用者ならDDoSぐらい常識なんだから一カ所からアクセスが来るぐらい別に何とも。
# いたずらとか転売とかなら止めたくなるのもわかるけど、ボットかどうかは関係ないしな。
そりゃ、予約のチェックに来てるボットだって最初から分かってるなら気持ち悪くないわな。
攻撃に来てるなら変なパラメータがぶら下がってたり、いろんなURLにがつがつアクセスしてたりと挙動ですぐわかるから大丈夫だわな。
攻撃している側が挙動を誤魔化すかもしれないと想定してない上に、よく分からんアクセスがあっても気持ち悪いとも思わない管理者とか恐ろしいな。
問題ないアクセスで問題起こすようなシステムの管理でもしてるの? 大変だね。よくわからんアクセスは問題あるアクセスか無いアクセスか切り分けるし、問題あるなら対策するだけ。よくわからん、きもちわるいで済ませちゃダメですよ。ちゃんと調べないと。
ごまかされただけで問題が起こるような作りならどうせ悪意のないアクセス過多でも問題起こすから、まず管理してるサイトの作りを見直すべき。人力F5で落ちないようにがんばりましょう。 後はセキュリティ系の勉強会やIPAで情報収集しといた方がいいね。
# つーか、DDoSって書いてるんだから大量アクセスぐらい想定済みだっつーの。# 何年前で止まってるんだよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
阻止したくなる (スコア:1)
逆にレストラン側の予約システムを作る側としては、きっとbotによる予約は阻止したくなるかも。
CAPTCHAを入れるとか。
個人的には人間でも読めないような難しすぎるCAPTCHAはイライラするのでダメだが、レストランの予約システム程度ならば簡易的なものでも十分だろう。
レストラン(のシステムを管理している担当)にとっては気持ちが悪いアクセスだし、システム障害に結びつく可能性もある。
Re: (スコア:0)
キャンセル待ち予約機能を付ければbotのターゲットにならない気がします。(たぶん有料機能で
Re: (スコア:0)
つーか、予約システムといっても受付はメールなのだから、
受け付ける側が「botしね」と思うなら、そのアドレスの自動受付拒否して、拒否メールでも返信すればいいよね。
ボール(bot予約を是とするか)はレストラン側にあって、
サービス不能になるほどの頻度でアクセスしない限り、
法的はもちろんマナー的にもどうこういう問題ではない。
Re:阻止したくなる (スコア:1)
状況をポーリングしてメールするまではともかく、予約までやっちゃうのはマナー違反と捕らえられると思います。 なにせ、エスカレートするとそれ以外で予約が実質的に不可能になっちゃいますし。
Re: (スコア:0)
>予約が実質的に不可能になっちゃいますし。
店側は常に満席だから文句はない。
Re:阻止したくなる (スコア:1)
オーナーシェフのインタビューみたいな記事でも、大抵、「ゆったりくつろいで貰えて、美味しかったよと言って頂けるのが最高に嬉しい」とか書いてあったりしますし。その方向性から乖離するのは迷惑なんじゃないかなぁ、と。 まあ、そこまでの人気店になったらそんな事も言ってられないでしょうし、本音では儲かったらなんでも良いのかもしれませんけど。
Re: (スコア:0)
単に予約の内容がまちがってたのでキャンセルして再登録しただけだったりして
Re: (スコア:0)
Re: (スコア:0)
https://gist.github.com/diogomonica/6076911 [github.com]
ソース見る限りWebフォーム登録ですね。
Re: (スコア:0, おもしろおかしい)
脆弱性スキャンや不正侵入を試みるアクセスにも見えて気持ち悪いよね。
単独で細々としてるならまだ良いが、複数のbotが頻繁に行うようになるとサーバの負荷も高まるし、リソース不足で障害になる可能性もあるよね。
岡崎市立図書館は警察に通報して逮捕させた点が批判されたけど、サイト運営側が変なアクセスから防御して健全性を維持しようとするのはいたって正しい行為だよ。
そんなこといちいち書かなくてもわかりそうなものでしょうけど、上から目線で質問して偉そうにする人っているのよね。
Re: (スコア:0)
横からだけど、システム運用も何もしたことがない人が、自分の無知をさらけ出しながら絡んでるようにしか見えないから、もう止めた方が良いと思うよ。
システム運用してたらむしろ平気だろ (スコア:0)
MDISの人?
システム運用してれば毎日のように明らかに不正アクセス狙いのログがあるんだから
ボットが予約のチェックに来るぐらい別に気持ち悪いことではないよ。クローラだって普通にあさりに来るし。
いまどきシステム運用者ならDDoSぐらい常識なんだから一カ所からアクセスが来るぐらい別に何とも。
# いたずらとか転売とかなら止めたくなるのもわかるけど、ボットかどうかは関係ないしな。
Re: (スコア:0)
そりゃ、予約のチェックに来てるボットだって最初から分かってるなら気持ち悪くないわな。
Re: (スコア:0)
攻撃に来てるなら変なパラメータがぶら下がってたり、いろんなURLにがつがつアクセスしてたりと
挙動ですぐわかるから大丈夫だわな。
Re: (スコア:0)
攻撃している側が挙動を誤魔化すかもしれないと想定してない上に、よく分からんアクセスがあっても気持ち悪いとも思わない管理者とか恐ろしいな。
Re: (スコア:0)
問題ないアクセスで問題起こすようなシステムの管理でもしてるの? 大変だね。
よくわからんアクセスは問題あるアクセスか無いアクセスか切り分けるし、問題あるなら対策するだけ。
よくわからん、きもちわるいで済ませちゃダメですよ。ちゃんと調べないと。
ごまかされただけで問題が起こるような作りならどうせ悪意のないアクセス過多でも問題起こすから、まず管理してるサイトの作りを見直すべき。
人力F5で落ちないようにがんばりましょう。 後はセキュリティ系の勉強会やIPAで情報収集しといた方がいいね。
# つーか、DDoSって書いてるんだから大量アクセスぐらい想定済みだっつーの。
# 何年前で止まってるんだよ。