スライド概要 SPA(Single Page Application)の普及が一層進んでおり、従来型のMPAを知らないウェブ開発者も生まれつつあるようです。SPA対応のフレームワークでは基本的な脆弱性については対策機能が用意されていますが、それにも関わらず、脆弱性診断等で基本的な脆弱性が指摘されるケースはむしろ増えつつあります。 本セッションでは、LaravelとReactで開発したアプリケーションをモデルとして、SQLインジェクション、クロスサイトスクリプティング、認可制御不備等の脆弱性の実例を紹介しながら、現実的な対策について紹介します。LaravelやReact以外のフレームワーク利用者にも役立つ説明を心がけます。 PHPカンファレンス2022での講演資料です。 PHPカンファレンスでの動画URL https://www.youtube.com/watch?v=jZ6sWyGxcCs
SPAのログイン周りについて、「これがベストプラクティスだ！」という情報があまり見当たらないので、様々な可能性を模索してみました。 いろいろな状況が想定され、今回記載する内容に考慮の漏れや不備などがありましたら是非コメントでご指摘いただきたいです！特に「おすすめ度：○」と記載しているものに対しての批判をどしどしお待ちしております！ この記事でおすすめしているものであっても、ご自身の責任で十分な検討・検証の上で選択されてください。 前提 想定しているAPIは、 ログイン外のAPIにはPOST/PUT/DELETEのものがなく、GETのみ GETのAPIにはDBを更新するなどの操作がない とし、そのためログイン外ではCSRFを考慮しなくてよい、 という前提で話を進めます。 また、XSSに関しては常に対策は必要なのですが（フレームワーク側が自動的にしてくれる部分もある）、認証周りに関係すること以
6. Hash によるルーティング URL の Hash （フラグメント識別子）を利用した方法 location.hash hashchange イベント http://localhost:8080/path/to#hoge 7. Hash （ JavaScript でのルートの扱い） location.hash を使う 遷移先ルートの設定 location.hash = 'hoge'; 現在のルートの取得 console.log(location.hash); // -> '#hoge' 8. （補足） location http://localhost:8080/path/to?a=1&b=2#hoge protocol http: host localhost:8080 hostname localhost port 8080 origin http://localhost:8080
[レベル: 上級] DeepCrawl が主催したウェビナーで Google の Martin Splitt（マーティン・スプリット）氏が、JavaScript サイトの SEO に関するさまざまな質問に回答しました。 このなかで、サーバーサイドでレンダリングすべき要素、言い換えると、JavaScript を介してレンダリングさせるべきではない要素をスプリット氏は挙げました。 スプリット氏によると、SEO を考慮するのであれば、次の要素はサーバーサイドでレンダリングしてからクライアント（ユーザーと Googlebot）に配信したほうがいいとのことです。 メインコンテンツ 構造化データ title タグ meta description hreflang 日付に関する記述 メインコンテンツは、ページの評価において最も重要です。 現在の WRS（ウェブ レンダリング サービス）が、古い Chr
最近のフロントエンドに関するお気持ち。正直まとまってはない。 最近、こんな感じのツイートや記事が増えた。 web 技術をキャリアの中心にしない シングルページアプリケーション (以下SPA) の台頭により、私の観測範囲ではモダンな Web サイトは SPA で作られるようになった。サーバーサイドは JSON を返す API サーバーとなり、DB やバックエンドシステムのプロキシのような存在になりつつある。 私はサーバーサイドエンジニアとしてキャリアを積んできた。SPA が流行りだした頃、いずれサーバーサイドエンジニアは不要になって自分のキャリアを考え直さなくてはいけない時期がくるのではないかと戦々恐々としていた。 自分も元々、SPA を他サイトとの「差別化技術」と定義していた。ブラウザのタブページのライフサイクルにおいて、初期化プロセスを一回にまとめてシームレスな遷移を実現する技術。たとえ
Vue.jsでSPAを作ったものの、検索エンジンのクローラーやSNSのOGP取得といった問題で困ったことはありませんか？ サーバーサイドレンダリングを簡単に構築できるNuxt.jsの活用方法を解説します。 ユニバーサル（Isomorphic）JavaScriptはJavaScriptコミュニティで一般的な用語になりました。ユニバーサルJavaScriptとは、クライアントとサーバーの両方で実行できるJavaScriptコードのことです。 Vue.jsを含むモダンJavaScriptフレームワークの多くは、シングルページアプリケーション（Single Page Application : SPA）の構築を目的に作られています。シングルページアプリケーションはページがリアルタイムで更新されるので、アプリの動きが軽快でユーザーエクスペリエンスが向上します。さまざまな利点がありますが、欠点もありま
従来のWebアプリケーションなら簡単なGoogleやFacebookのソーシャルログインも、シングルページアプリケーションに実装するのは意外と大変。実装に戸惑った方へ、ちょっとしたコツを教えます。 シングルページアーキテクチャーを使って開発されたWebアプリケーションを目にすることが多くなりました。このアーキテクチャーでは、アプリケーション全体がJavaScriptとしてブラウザーに読み込まれ、サーバーとのやりとりはすべてJSONドキュメントを返すHTTPベースのAPIを使って実行されます。こうしたアプリケーションはユーザープロファイルを保存するときをはじめ、特定のユーザーに操作を限定する必要があります。この処理は従来のHTMLベースのアプリケーションでは比較的簡単に実装できましたが、シングルページアプリケーションではすべてのAPIリクエストを認証しなければならないため、難度が上がります。
ブラウザでの Javascript の高速化と Backbone や Angular のような JavascriptMVC フレームワークの登場により、以前より SPA（Single page application）が構築しやすくなりました。 さらに、Yeoman に代表される SPA を作成するするための scaffold（土台）が整備されてきましたので、結構さくっと SPA が作れるようになったのも事実です。 さくっと作った SPA がさくさく動かない・・・作ったけど使えない・・・なんてことにならないように、SPA を構築する前に知っておいた方がいい課題について調べてたり考えてみました。 目次 1. パフォーマンス 2. メモリリーク 3. セキュリティ 4. フレームワークロックイン 5. 画面設計から UI コンポーネント設計への思想転換 6. フロントエンジニア不足 7. 番外
いわゆる SPA + サーバーサイドレンダリングがダルい 唐突ですがおさらいです。 なぜサーバーサイドレンダリング（SSR）が嬉しいかと言えば 初期表示の Critical Rendering Path を短縮できる SEO における保守信仰にやさしい（） 古いブラウザ・低性能マシンにやさしい yahoo/fluxible による SPA + Server Rendering の概観 ::ハブろぐ であり、特に SPA + SSR の文脈においては Universal Architecture による SPA + SSR は、技術的には過渡期の歪なキメラっぽさが拭いきれませんが、昨今の Web フロントエンドにしては珍しくビジネス的な説得力があります。 SSR なのでSNSや検索からの流入による初期表示が速い SPA なので回遊時のページ遷移も速い SSR なので古いブラウザでも CSS
◆ フロントサイド(Javascript)でもできるし、サーバサイドでもできる ※ Javascriptは以下Jsと呼ぶ Webシステムを製造するとき、フロントサイド(Js、もしくは、AltJS）とサーバサイドの開発があります。10年前ぐらいは、もっぱらサーバ側でPHP、Javaなどでビューに関する処理を行っていました。それは、通信環境、ブラウザの性能など様々な要因でそうなっていたと思います。 いつしかAjaxの技術の普及に伴い、フロントサイドでJsを使うことが一般化してきました。そして最近では、SPA(Single Page Application)フレームワーク全盛の時代で、React、Angular2、Vue、Riot、Mithrilなどを使うことが一般化してきました。 ▶ View開発のサーバサイドからフロントサイドへの変遷（Javascriptの台頭） フロントサイドでのJs開発
複雑なシンプルページアプリケーション（SPA）こそテストが大事ですが、手作業でやるには大変。そこで、Laravelのテストライブラリー「Dusk」を使ってみましょう。 JavaScriptアプリケーション、特にシングルページアプリケーションにおいてエンドツーエンドテストは常に課題です。Laravelは最近、その課題の打開案となる新しいテストライブラリー、Duskの5.4バージョンをリリースしました。 今回のDuskのリリースで、Laravelはユーザーにブラウザーテスト用の共通APIを提供するようになりました。デフォルトでChromeDriverが付属し、ほかのブラウザーのサポートが必要な場合はSeleniumを使用できます。ニーズに応えるために、今後もこの共通テストAPIをサポートされる予定です。 この記事では、新しいLaravel 5.4アプリケーションを紹介します。 インストール c
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
