February 21, 2007
Warning!! Page Expired.
PHP 警告 : ページの有効期限切れ
POSTを使繧?なければでないのだが、IEのキャッシュがいっぱい2になったときの臀??様である。
session_cache_limiter('private, must-revalidate');
かならず再読み込みをする。入力フォームで入れた情報が消える場合がある。入力値をクッキーでカバーできるならこれ縺?OK。
session_cache_limiter('private_no_expire');
入力フォームのデータなどは觸??えないが必ずcacheを読むため、リロードで古いものを見せ続ける危険性がある。
<a href="form.php?<?=time(); ?>">Go Form</a>
リンクをユニークにすると藹??ず再読み込みするようになる。
if (0 < count($_POST)) {
session_cache_limiter('private_no_expire');
}
POSTのときだけcacheを有効にする。ブラウザの戻るボタンで戻る縺?POSTできていない先頭ページは入力が消えている。
<a href="form.php?doCache">Go Form</a>
if (0 < count($_POST) || array_key_exists("doCache", $_GET)) {
session_cache_limiter('private_no_expire');
}
cacheしたいとき縺?cache指定、POSTのときは強蛻?cache。
--------------
■PHPのバージョンによるのか新情蝣?
session_cache_limiterの藹??数縺?
none/nocache/private/private_no_expire/public
のいずれかしか藹??け付けず、その臀??の値をセットする縺?publicを指定した場合と同じ縺?session_cache_limiter('private, must-revalidate')はキャッシュ制御ヘッダが送信されない
1) nocache:クライアント/プロキシのキャッシュを無蜉?
2) public:クライアントマシ繝?/プロキシのどちらもキャッシ繝?
3) private:クライアントマシンのみキャッシュ臀??持。Expireヘッダが送信されます
4) private_no_expire:privateと同じだがExpireヘッダはクライアントに送信されません。有効期限切れを回驕?
フォームの入力内容を保持して、ブラウザの戻るで戻りたい場合は、private_no_expireかnoneがいいみたいだ
笳?session_cache_limiter('private_no_expire');
期限切れが出に縺?いがキャッシュばかり使う(静的ページ、静的なページのフォーム)
※運用時縺?private_no_expireでも開発時縺?none縺?
笳?session_cache_limiter('nocache');
戻ると期限切れがでる(動的ページ、フォームには向かない)
笳?session_cache_limiter('none')
キャッシュヘッダを出さず、期限切れが出に縺?縺?適時読み込みをするがブラウザによる(動的なページのフォーム、更新がよ縺?觸??かる静的ページ・??
笳?フォームに戻ってキャッシュ臀??杯で期限切れを出し、更新ボタンで再ポストを避けたい
期限切れを出さないフォームは、GETかsession_cache_limiter('none');かsession_cache_limiter('private_no_expire');
2重登骭?NGなフォームは、DBMS縺?PKやユニークをチェックさせるか、トークンを使うか、処理後リダイレクト
笳?トーク繝?
1)フォーム表示時点で、画面縺?hiddenにキーを、セッションにもキーを仕込んでお縺?。
$taskId = mt_rand();
$_SESSION['taskId'] = $taskId;
print('<form action="submit.php" method="post">');
print('<input type="hidden" value="' . md5($taskId) . '" name="taskId" />');
print('<input type="submit" value="submit" name="submit" />');
print('</form>');
2)登録処理のとき、画面から来たキーとセッションに格軆??されているキーを比較して、正し縺?フォーム表示の画面から遷移しているか確鐔??する。
<?php
//二重登録防止フォーム-登録処理
session_start();
$taskId = $_SESSION['taskId'];
unset($_SESSION['taskId']);
if (md5($taskId) == $_POST['taskId']) {
print('きちんと前の画面からsubmitされています。');
//登録処理後に藹??了画面縺?HTTPリダイレクトで遷移するようにしておけば特別な対策なしでも完了画面をリロードされても問題なし
header(‘Location: 完了画髱?URL’);
} else {
//二重登録された場合や、直接アクセスされた場合の処理
print('フォームを通してアクセスして臀??さい。');
}
Posted by funa : 07:56 PM
| Web
| Comment (0)
| Trackback (0)
February 20, 2007
The No-Asshole Rule
http://yotophoto.com/
http://www.sxc.hu/
http://www.morguefile.com/
http://www.burningwell.org/gallery2/main.php
http://davidniblack.com/imagebase/
http://www.freephotosbank.com/
<!-- This is my advice for the OLD-FASHIONED man who can NOT take resonable alternatives in mixed COMPLEX stuation. Need learn MBA not PM. PM depends on age. MBA brings everybody who wants to be in this ganeration of IT a pillar. NEXT is ... -->
スーパーのレジ打ちを顧客自身がやってはいけないのか?早く店を出ることができるようになったら、その方が顧客は喜ぶのではないか?と考える
Roger that.
Posted by funa : 07:51 PM
| Web
| Comment (0)
| Trackback (0)
February 17, 2007
htaccess mod_rewite
mod_rewiteの設定縺?.htaccessに鐔??載していることだと思うが、ヘンテコな設定はかなりApacheに鐔??荷を觸??け、Temporary Service UnavailableやForbidenなどのエラーを頻発させてしまう。
よく使繧?れる設藹??は、次のようなものだ。
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^db/([0-9A-Za-z]+)_(.*)\.html$ db/db\.php?id=$1 [L]
RewriteCond %{REQUEST_FILENAME} !-d は「ディレクトリが存在しない場合」
さらに、次縺? RewriteCond %{REQUEST_FILENAME} !-f は「ファイルが存在しない場合」
リクエストされたディレクトリまたはファイルが存在しなければ、mod_rewiteのルール処理に鐔??縺?よ。ということである。つまりルートディレクトリに置いた日には無饅??縺?Apacheのリソースを喰ってしまうのである。dbディレクトリ縺?htaccessを置縺?など、ディレクトリ觸??に設定する方軆??をとる必要がある。
また、ルール処理にできるだけ行かせないようにする記載方觸??も併せて施軆??としたい。
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !\.(css|gif|jp?g|png)$
RewriteCond %{REQUEST_URI} !^/images/.*$
RewriteCond %{REQUEST_URI} !^/s/.*$
RewriteRule ^db/([0-9A-Za-z]+)_(.*)\.html$ db/db\.php?id=$1 [L]
Posted by funa : 06:29 PM
| Web
| Comment (0)
| Trackback (0)
February 5, 2007
Copyright Protection
違法コンテンツがサーバーにアップロードされており、他人の権利が侵害されていることを知っていた、あるいは知るに足る相藹??の理由がある場合、損害鐔??償責任を負います。それ以藹??の場合には・??著作権者等に対して損害鐔??償責任を負いません。これがプロバイダ責任制限法です。
直ちに削除・??あるいは送信防止措置・??の対応をとっていれば、プロバイダは著作権者等に対し責任を負繧?ないと鐔??えます。
ただ、誰が著作権者なのか、コンテンツが違法なのかは、必ずしも譏?確ではないため、プロバイダ責任制限法ガイドライン軆??検險?協議臀??が作成した
ガイドライ繝?があります。
著作権関臀??信頼性確認団臀??からプロバイダに申し出があった場合の対処方觸??なども。
もちろんプロバイダ責任制限法には免責されない例外的な場合があります。サービス觸??供者自身が違法コンテンツの「発信者」もし縺?は軆??極的に関繧?る場合には免責が藹??けられません。
-
IT法律入門-
投稿者を特藹??する方觸??
Posted by funa : 09:56 PM
| Web
| Comment (0)
| Trackback (0)
February 3, 2007
Link Bait
リンクベイティン繧? 6つのテクニッ繧?
1. 情報觸??供で釣る
「 X のまとめ」といった特藹??分驥?に関する包括的な情報をまとめたコンテンツを餌にする
「 X に関する n 個の効果的な方觸??」のような特藹??分驥?に関する How to や Know How のリストを餌にする
「 X を Y できる便利ツール」といった特藹??分驥?に関する役軆??つツールの紹介コンテンツを餌にする
* 国藹??ではホワイト・ペーパーや無料レポートをエサにするケースが多いよう。
2. ニュースで釣る
「速報・?? X が Y を発表」といったように、本物のスクープを餌にする
「 X 社縺? Y 報道について思う」といったように、元のソース以上に釣りとしての味臀??けを加えてニュースを伝える
「スクープ! X 事件縺? Y 縺? Z だった」といったように、誰かの正体を暴縺?ことや詐欺の全容を解譏?することを餌にする
3. 藹??対表譏?や攻撃で釣る
「 X の発鐔??縺? Y の点で間違っている」のような、有名人や有名ブロガーなどの特藹??個人に対する藹??論を餌にする
「 X たちが Y するのは臀??快」のような、特藹??の集団に対する不快感を表譏?することによって鐔??争を引き起こす
「 X 縺? Y と鐔??っているが実縺? Z」のように、特藹??の個人や集団に対する藹??証を上げて攻撃することで鐔??争を引き起こす
4. ユーモアで釣る
「衝撃!まる縺? X のよう縺? Y 画蜒?」のような形で、flickr などで鐔??つけてきた面白い画蜒?を餌にする
「 X が Y する決藹??的瞬間」のような形で、YouTube などで鐔??つけてきた面白い動画を餌にする
「 X とかけ縺? Y と解縺?。その藹??は・??」や、
「 X なの縺? Y とはこれいかに・??」のような藹??番を使って藹??咄を作り、餌にする。
5. 煽りによって釣る
「あなたが考えているほ縺? X 縺? Yではない」や、
「勘違いするな・?? X 縺? Y ではない」や、
「 X は本藹??縺? Yか?」や、
「 X も絶鐔??、今流行縺? Y の軆??密に迫る」など、女性週刊誌や午後のワイドショーのような煽りを餌にする
「 X な人が陥りがち縺? Y の落とし穴」のように、男性鐔??にありがちな煽りを餌にする
「知らないと損する! X に関する n 個の知鐔??」のような形で、相手の無知に対する危觸??感を煽る
「 X 縺? Y ですが何か?」や、
「はいはい X を Y した俺が来ましたよ」や、
「 X 縺? Y が激し縺? Z す縺?る件」に代表されるようなものも日本のネットコミュニティにおいては鐔??られる
6. レビューで釣る
「 X の新製品 Y のここが凄い」といったように、話饅??の製品について藹??化をつけた視点からのレビューで釣る
「あの新名所 X に鐔??ってきました」のように、話饅??の場所やサービスの觸??行に便乗する形のレビューで釣る
「話饅??縺? X に觸??む危険す縺?る Y 」といったように、話饅??の製品やサービスについての批判的な側面からのレビューで釣る
Posted by funa : 08:34 PM
| Web
| Comment (0)
| Trackback (0)
February 1, 2007
Personal Information Privacy Act
警藹??からの・??情報開示など・??捜査臀??頼が来た時マニュア繝?
1) 本物の警察かどうか
警藹??の番号は臀??4桁が「0110」になるのがルール、電話番号を聞きこちらからかけ直す。
2) 投稿の削除臀??鬆?
拒否しても構繧?ない。警藹??からの削除臀??頼だからといって無条件で削除する義務はない。内容が正藹??だと思ったものに関しては削除できない旨を伝える。
3) 投稿者の個人情報の開遉?
- そのままメールや電話で開示する
- 捜査関臀??事項照臀??書を送ってもらい文書で開示する
- 裁判所からの令状があり次第開示する
基本的に、警藹??からの開示鐔??求の段髫?では義務はない。あ縺?まで「お願い」の状態だからである。一番リスクが少ないのが裁判所からの令状があり次第開示するというものですが、余計な手間を避けるため「捜査関臀??事項照臀??書を送って縺?れ」と臀??えて送ってきたものに関して文書で開示する方觸??が妥藹??か。メールや電話で開示しても、プロバイダ責任制限法案があるので、責任が蝠?繧?れることはほぼない。
伝えるべき内容は以下。「こちらでは投稿者の発信者情報しか藹??得しておらず、それしか開示できません。その情報を持って、プロバイダに開示鐔??求をしてださい。」
4) 警藹??対藹??の注諢?轤?
警藹??への対応の臀??番の注諢?点は、警藹??は「判断者」ではない、ということです。警藹??の鐔??求に藹??えて鐔??動したからといって、その鐔??動が正藹??なものであるかどうかは臀??証されません。その鐔??動について責任を蝠?繧?れる可能性もあります。(警藹??が「人を殺せ」といったから殺した、という理由が通らないのと同じ)
///メディアトレーニン繧?
http://www.bangboo.com/media/
Posted by funa : 08:00 PM
| Web
| Comment (0)
| Trackback (0)
February 1, 2007
Browser becoming a Push Media
WEBブラウザの臀??組みとして、まず第臀??にクライアントからのアクションがなければブラウザにデータが送られることはなかった。しかし、この課題を解觸??する方觸??として、非同期通信を採用したのがAjaxである。だがAjaxにしても、定期的に蝠?い合繧?せ(ポーリング・??しなければならなかった。現在もっともリアルタイムにプッシュ通信させる方觸??とし縺?"Comet"がある。Webクライアントから縺?HTTP要求に対して、すぐには鐔??答を返さず、メッセージの追加などサーバサイドでのアクションをトリガーにして鐔??答するというものだ。
-
Lingr API
Posted by funa : 12:10 AM
| Web
| Comment (0)
| Trackback (0)
January 27, 2007
Classic Font
Frutiger
Akzidenz Grotesk
Interstate
Avant Garde
Rotis
Gotham
Cooper Black
Blur
Miller
Clarendon
Bello
http://www.100besteschriften.de/
モト繝?
Holiday MDJP02
キャパニト・アニト・セプテンバー・あられ・えれがんと・東縺?ずれ
切り文字
モフ字
S2Gシリー繧?
あ縺?あフォント
しねきゃぷしょん
じゃぽね縺?す
あずきフォント
うずらフォント
怨霊フォント
あんずもじ
えるまーフォント
ウナオジャポン・鞦韆堂フォント・昭和繝?スタルジ繧?
和田研細丸ゴシッ繧?
きろ文字
ふいフォント・まきばフォント
ほにゃ字
青柳衡螻?
AXIS Font
たれフォント
白舟角崩白文・白舟角崩朱文・白舟髭髫?
白舟書臀??
M+フォントシリー繧?
VLゴシックフォントファミ繝?
梅フォント
みかちゃんフォント
ゆたぽんシリー繧?
アームド・バナナ
アームド・レモ繝?
KFひま藹??
http://blog.4galaxy.net/56.html
■その臀??フォントURL
http://www.dafont.com/
http://photoshopvip.net/archives/18187
tondo - maagkramp
ptf_nordic
japan
melbourne
telegrafico
streetvertising
Posted by funa : 11:32 PM
| Web
| Comment (0)
| Trackback (0)
January 8, 2007
Is this English???

-
Is this English??? このブログは、ある英鐔??力の荒廃に戦いを挑んだ熱鐔??ブロガー達の鐔??録である。英鐔??ブロガー界においてまった縺?無名の弱体チームが荒廃の中から健全な精神を培い繧?ずか数年で藹??国制鐔??をなし遂げた奇跡を通じて、その藹??動力となった信頼と愛を余すところな縺?ブログ化したものである。
Posted by funa : 02:41 AM
| Web
| Comment (0)
| Trackback (0)
January 2, 2007
Passwords
MySpaceのフィッシングで藹??集されたパスワード、最多は「password1」
最も多かったパスワードは「<strong>password1</strong>」で全臀??縺?0.22%,次の藹??かった「abc123」と「myspace1」は・??それぞれ0.11%だった。これら以降は・??多い順に「password」「blink182」「qwerty1」「<strong>fuckyou</strong>」「123abc」「baseball1」「football1」「123456」「soccer(0.04%)」「monkey1」「liverpool1」「princess1」「jordan23」「slipknot1」「superman1」「iloveyou1」「monkey(0.02%)」――
Posted by funa : 10:32 PM
| Web
| Comment (0)
| Trackback (0)