CEL(Common Expression Language)で書いた条件にマッチしたIAM Policyを見つける / iam-policy-finder
CEL(Common Expression Language)で書いた条件にマッチしたIAM Policyを見つける / iam-policy-finder
その1. そもそもアイデアが思い浮かばない 遭遇確率 :★★★★☆ どんな壁?:いざWebサービスを作ろうとしても何もアイデアが思い浮かばない 解決策:身近な課題をひたすら探す サービスを作る上では何かを解決する系のアイデアであり、かつ自分が当事者であるとモチベーションも続きやすいです。 自分が普段ネットを使っていて不便だと思うこと、今使っているサービスの不満点、などなんでも良いのでとりあえず書き出してみましょう。 大体この中に自分の技術力でも解決できるような課題が存在します。 もし自分の中での課題が見つからないという場合は、日々Twitterのタイムラインで流れてくる身近な人が抱えている課題をピックアップしてアイデア化するのもありです。 回避策:しょぼいアイデアでも日々書き残していく いざサービスを作るというときにアイデアも出ないし身近な課題すら見つからない場合は、普段からアイデアを無理
本連載では第一線のPerlハッカーが回替わりで執筆していきます。今回のハッカーはnekokakさんこと小林篤さんで、テーマは「ジョブキューで後回し大作戦」です。 ジョブキューとは 一時代前は時間のかかる処理もすべてWebアプリケーションで行っていましたが、最近ではいろいろな部分で処理の非同期化が行われるようになってきました。たとえばWebのインタフェース側ではAjaxがその最たるものでしょう。アプリケーションのバックグラウンド側でも今回のテーマであるジョブキューと呼ばれるしくみが多く利用されるようになりました。ジョブキューを賢く上手に利用することで、ユーザにストレスを与えることなく、またサーバのリソースも有効に使えるようになります。 ジョブキューは延々と動き続けるバッチ処理、というイメージが最もわかりやすいでしょう。通常のバッチ処理であればcrondを利用し、一定周期でプログラムを起動して
This document contains code snippets and technical details from various programming languages and frameworks. It includes examples of database queries, model associations, HTTP requests, pagination, and tracking model changes in Ruby on Rails. Thread-local storage is demonstrated using RequestStore to make request information available across different parts of a Rails application.Read less
先日の Web Crypto API の基本的な使い方の解説(改訂済み)においては、説明を簡単にするために AES-GCM の初期ベクトルを乱数に基づいて生成しましたが、これはセキュリティの観点からはあまり好ましくありません。本記事では、Web Crypto API で AES-CBC や AES-GCM を用いて暗号化する場合の、より安全な初期ベクトルの生成方法について解説します。 望ましい初期ベクトルとは? 前の記事でも述べていますが、初期ベクトルについて簡単におさらいします。 共通鍵暗号のアルゴリズムである AES にはいくつかの「暗号モード」があり、中でも CBC や GCM といったモードでは、暗号化に際して初期ベクトルというパラメータが必要となっています。これは、データを暗号化する際に添加する無関係のデータのことで、それによって暗号文から元のデータを予測しにくくするという意味が
株式会社クリアコード > ククログ > Webアプリや拡張機能(アドオン)で、Web Crypto APIを使ってローカルに保存されるデータを暗号化する ※注記:本文末尾の「公開鍵暗号ではなく共通鍵暗号を使う理由」の説明について、2019年1月30日午前0時から21時までの間の初出時に内容の誤りがありました。また、2019年1月30日午前0時から2月5日20時頃までの間において、本文中での AES-CTR による暗号化処理が、 nonce を適切に指定していないために脆弱な状態となっていました。お詫びして訂正致します。初出時の内容のみをご覧になっていた方は、お手数ですが訂正後の説明を改めてご参照下さい。 クリアコードで主にMozilla製品のサポート業務に従事している、結城です。 FirefoxやThunderbirdがSSL/TLSで通信する際は、通信内容は自動的に暗号化されます。その一
TLS • TLS (reliable) endpoint endpoint CC BY 3.0 https://www.youtube.com/user/TheWikiLeaksChannel ClientHello+ ApplicationData end_of_early_data Finished ServerHello EncryptedExtension ServerConfiguration Certificate CertificateVerify Finished ApplicationData
複数回に渡って 分かりそうで分からない Cookie(クッキー)について取り上げていきます。 第一回は、セッションCookieについて説明していきます。 Cookieはわかりにくい? セッションCookieとは? なぜ、セッションCookieが必要? セッションCookieの有効期限(サーバ) セッションCookieの有効期限(ブラウザ) Cookieはわかりにくい? Cookie(クッキー)は、Webサービスの利用ユーザーにとっては分かりにくいものですよね。 なぜなら、HTTPヘッダーというヘッダーに格納される情報で、意図的に確認しない限りは分からないためです。 あとは、このCookieがくせ者な理由は サーバー、ブラウザで使われている言葉が異なる点です。 例) サーバーではセッションID、同じ情報をブラウザではCookieやセッションCookieと呼んでいます なんとなくCookieは
関連記事 WebTransport over QUICのサンプルサーバを試してみる - ASnoKaze blog WebTransport over HTTP/2 の仕様について - ASnoKaze blog WebTransport over QUIC について - ASnoKaze blog WebTransportという新しい双方向通信フレームワークの議論が始まっている。 GoogleのPeter Thatcher氏らによって、W3C WICGにプロポーザルが投げられています。 discourse.wicg.io WebTransportは、WebSocketのようなAPIをもち、QUICやHTTP/3上で多重化されたストリームを利用し、ヘッドオブラインブロックのない通信を行えるようにするというのがモチベーションのようです。(実際に使用する"トランスポート"はプラガブルな設計にな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く