Explore issues and events in detail. Curated by the Trends Data Team.
![Google Trends](https://cdn-ak-scissors.b.st-hatena.com/image/square/e125934446304dfe170bf60385016f04a74b4d5e/height=288;version=1;width=512/https%3A%2F%2Fssl.gstatic.com%2Ftrends_tpt%2Ffb29f61e3b0419e1e745c9245d00d094c5357b2246bbdf17cd2b03d7349b2c72.png)
WebアプリケーションフレームワークWicketが正式リリースされたのは2005年の6月。まもなく1年を迎ようとしている。Wicketは、Webアプリケーションの開発を容易にするため、それまでのフレームワークとは一風変わったアプローチを取っていることで注目された。Wicketの現在の最新版はバージョン1.1.1であり、6月には様々な改良が加えられたWicket 1.2がリリースされる予定になっている。本稿では、そのWicketを使用して簡単なWebアプリケーションを作成する方法を紹介する。 Webアプリケーションフレームワーク いわゆるWebブラウザから操作するWebアプリケーションを開発する場合、いちからすべて作成するということはまずない。まず基本となるWebアプリケーションを決め、実現したい機能から必要になるライブラリをそろえ、それらを組み合わせてシステムの開発をおこなう。 Javaを
サンプルで覚える XSLTプログラミング 小山尚彦、Chienowa.comチーム 日本オラクル株式会社 2000/8/22 2000/10/12(第9章以降追加) XMLは文書の記述の表記基準に過ぎません。ですから、XMLがその真価を発揮するにはさまざまな要素が必要です。例えば、XML文書のデータ構造を、XML文書をやり取りする人々のあいだで定義しておくことは大切です。そのために、DTDや最近ではXML SchemaというXMLデータ構造を表記する基準(スキーマ言語)が検討されています。 また、XML文書をさまざまな形式に加工することも重要でしょう。しかも、 そのような加工の方法もXMLで書かれたならなおよいでしょう。 それがXSL(Extensible Stylesheet Language)です。 XMLを自由に加工できる XSLはXSLT(XSL Transformation)と、
独立行政法人 情報処理推進機構(IPA)におきましては、安全なインターネットの利用をめざして、最近、IPAが届出を受付けたウェブアプリケーションの脆弱性関連情報などを基に、影響度が大きい脆弱性を取り上げ、その解決策を紹介するセキュリティ実装講座を企画いたしました。 ウェブアプリケーションの開発者・技術者および研究者を対象としていますが、ウェブサイトへの新たな脅威に関する内容も含まれるため、ウェブサイト運営者の方々にもご聴講をお勧めします。 記 1.日時 第1回:平成18年2月28日(火) 13:00 ~16:15 受付は終了しました。 第2回:平成18年4月 4日(火) 13:00 ~16:15 受付は終了しました。
(3/30 タイトル変えました。) SLE(Simple List Extensions)の形が見えてきた。MicrosoftのTeam RSS Blogで、Mix06というイベントで発表された、Amazon、eBay、Yahoo、MSによるSLEの実装が紹介されている。 At Mix06 last week, Dean Hachamovitch gave the keynote address on Next Generating Browsing, during which he showed off great live examples of feeds that implement the Simple List Extensions, built by Amazon, eBay, Yahoo, and MSN Spaces. 同エントリでは、movieによる紹介もある。 SLE
The Web Standards Project is a grassroots coalition fighting for standards which ensure simple, affordable access to web technologies for all. Skip to content InterAct: Web Standards CurriculumInterAct is a living, open curriculum based upon web standards and best practices, designed to teach students the skills of the web professional. InterAct Learning TracksThe InterAct curriculum framework has
his document は http://www.apache.org/docs/mod/mod_rewrite.html にある Apache Group によるオリジナルの mod_rewrite マニュアルを補足するものです。ウェブマスターが普段、実際に直面している典型的な URL-based の問題を、mod_rewrite でどのように解決するかを記述しています。URL の rewriting ruleset を設定することによってそれぞれの問題を解決する方法を詳述してあります。 Table Of Contents はじめに 解決策 URL レイアウト Canonical URLs Canonical Hostnames DocumentRoot の移動 ディレクトリのスラッシュの解決 均一な URL 配置をした ウェブ・クラスタ 異なるウェブサーバへのホーム・ディレクトリの移
まだあまりメジャーでないけれども、面白いサイトを教えてください。 誰に聞いても知っているようなサイトはいりません。
2006-04-06 近況 その夜, arai さんが "YAPC はすごかった" と興奮気味に話しているのを聞きながら, 私は perl の苦い記憶を玩んでいた. perl に何度も挑戦して全敗したあの頃. 私は perl を挫折したという理由から ruby を使っている. perl が perl でなかったら, 学生の頃にもっと CGI を作ったりして 今時の若者になれたのに.... そう思い, perl を使える人々を羨んでいた. (もちろん単なるいいがかり. なにしろ私の借りてきたサーバは 歴代すべて ruby がインストールされていたのだから.) で, YAPC Asia のスライドのうち perl 指数が低くミーハー指数の高いものを眺めた. mixi と はてな...と思ったら mixi はスライドないじゃん. なので はてなのスライド(PDF) だけ眺める. あまり perl
水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest(ヘッダおよび、POSTの場合はボディを含む)を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse(ヘッダおよび、HTML)を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更
前回はWTPの環境を準備しました。今回はいよいよ、Webプロジェクトを作成して実行してみましょう。この記事では、肥満度計算機を作成します。身長と体重を入力するとBMIという肥満度を表す数値を表示するといった、簡単なアプリケーションです。 Webプロジェクトの作成 今回のアーキテクチャはJSP Model 1.5を採用します。すなわち、フロント・コントローラは使わず、ビジネス・ロジック(BMIの計算そのもの)は JavaBeanで実装し、入力画面と結果表示画面はJSPを用いる、という構造にします(図1)。 空のプロジェクトを作る まず、空のWebプロジェクトを作成します。メニューから[ファイル]→[新規]→[その他](Ctrl-N)で表示される[新規]ダイアログから、[Web]→[動的Webプロジェクト]を選択し[次へ]をクリックします。プロジェクト名はここでは[webPrj]にしておきまし
新たなXSS(CSS)脆弱性、EBCSS 2006-03-30 かなりヤバめなXSS的攻撃方法が見つかりました。詳細は以下のリンク先をご覧下さい。 文字コード(SJIS)とHTMLエンコードとCross-Site Scriptingの微妙な関係 文字コードとHTMLエンコードとCross-Site Scriptingの微妙な関係 (EUCの場合、UTF-8の場合) 何がヤバいのかというと、この攻撃方法に対する根本的対策がほとんどのサイトで行われていないと思われるからです。 今までCross-Site Scripting脆弱性への対策はHTMLで使われる文字列を実体参照に変換するのが基本でした。しかし、マルチバイト文字列の仕様を突いて半端な文字列を送信しクオート文字を無効化(escape)することで、実体参照に変換されていてもスクリプトの実行が可能なケースがあることが判明したのです。 ちなみ
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
_ なぜCSSXSSに抜本的に対策をとることが難しいか CSSXSSの説明について、その脅威を過剰に表現している部分がありました。その部分について加筆訂正しています。 @ 2006/4/3 tociyukiさんによる「[web]MSIE の CSSXSS 脆弱性とは何か」および「[web]開発者サイドでの CSSXSS 脆弱性対策」には、より正確なCSSXSS脆弱性の内容およびそれに対するサーバーサイド開発者で可能な対策について紹介されていますので、是非そちらもご覧ください。 @ 2006/4/4 今までも何度かこの辺の話はあまり具体的ではなく書いてきたけど、そろそろCSSXSSを悪用したい人には十分情報が行き渡っただろうし、具体的な話を書いてもこれ以上危険が増すということはないだろうから、ちょっと具体的に書いてみる。 ちなみに私自身は、CSSXSSの攻撃コードなどを実際に試したりといった
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く