PHPカンファレンス小田原2024 の発表資料です。 https://phpcon-odawara.connpass.com/event/296492/ https://fortee.jp/phpconodawara-2024/proposal/7c57d5ca-213a-4d7a-aaf0-26ddc44897f0
PHPで動作するデータの暗号化・復号化のメモです。 通信時やDBのアクセス時などで使用します。 動作環境 PHP 7.3.11 プロトコル AES-256-CBCを使用します。 const AES_KEY = 'tekitou_key'; const AES_IV= 'tekitou_iv'; /** * 暗号化 * @param string $data * @return string */ function encrypt($data) { return $data === null ? null : openssl_encrypt($data, 'AES-256-CBC', AES_KEY, 0, AES_IV); } const AES_KEY = 'tekitou_key'; const AES_IV= 'tekitou_iv'; /** * 復号化 * @param stri
KUSANAGIはプライム・ストラテジー株式会社が開発している超高速LAMP, LEMP, WordPress環境です。 バーチャルドメインマネージャーとしても有用です。 ● バージョンアップ前に現在のKUSANAGIのバージョンを調べておく sudo kusanagi --version KUSANAGI Version 8.4.5-7 ● KUSANAGI 本体のバージョンアップ sudo yum update -y こちらのコマンドでエラーが出る場合があります。 その場合はこちらのコマンドからアップデートを行います。 ● KUSANAGI 本体のバージョンアップ(エラーが出る場合) sudo yum update -y --enablerepo=remi,remi-php56 ● バージョンアップが完了したら再度バージョンを確認する sudo kusanagi --version K
などとすれば、PHPのExtensionsが導入出来ます。 さてじゃあここで追加出来るExtensionsって何ぞや、と思っていたら、 Dockerfileのビルドエラー時に一覧が出てきたので、備忘録的に記録。 Possible values for ext-name: bcmath bz2 calendar ctype curl dba dom enchant exif fileinfo filter ftp gd gettext gmp hash iconv imap interbase intl json ldap mbstring mcrypt mysqli oci8 odbc opcache pcntl pdo pdo_dblib pdo_firebird pdo_mysql pdo_oci pdo_odbc pdo_pgsql pdo_sqlite pgsql phar pos
はじめに カレンダーのシステムを作ることになったので、日付けを週ごとに並べる為のグループ分けするロジックが必要になりました。 PHPの関数には、対象の日付が月の何周目なのか調べるものがありません。 仕方ないので自作することにしました。 環境 PHP: 7.1 導入手順 以下のロジックで計算することができます。 // 対処の日付 $TargetDay = date('Y-m-d'); $WeekNum = intval(date('w', strtotime($TargetDay))); $j = intval(date('j', strtotime($TargetDay))); $WeekEndDay = $WeekNum != 6 ? (6 - $WeekNum) + $j : $j; // 結果 return ceil($WeekEndDay/7); 解説 考え方としては、日付を週の統
PHP のバージョンは 5.4、MySQL のバージョンは 5.5 の環境を構築します。 Apache のバージョンは特に気にしていません。 ディレクトリ構造 ディレクトリ構造は以下のようになります。 . ├── config │ ├── mysql │ │ ├── Dockerfile │ │ ├── initdb.d │ │ │ └── init.sql │ │ └── my.cnf │ └── php │ ├── Dockerfile │ ├── apache2.conf │ ├── php.ini │ └── sites │ ├── 000-default.conf │ └── default-ssl.conf ├── data ├── docker-compose.yml └── html └── test ├─
php-fpmを使いましたが、思わぬところで仕様が違うので困りますね・・。 $_SERVER['PHP_AUTH_USER']と$_SERVER['PHP_AUTH_PW']を使ったphpでbasic認証をかけるソースがある場合は以下のようにやります。 .htaccess RewriteEngine On RewriteCond %{HTTP:Authorization} ^(.*) RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] php list($_SERVER['PHP_AUTH_USER'], $_SERVER['PHP_AUTH_PW']) = explode(':' , base64_decode(substr($_SERVER['REDIRECT_HTTP_AUTHORIZATION'], 6)));
if (filter_var($mail_address, FILTER_VALIDATE_EMAIL)) { return true } else { return false } 上のPHPコード「のみ」で判定しているサービスは、いますぐそれをやめましょう。 理由 時代はさかのぼり、牧歌的インターネットの時代。なりすましメールなど考えることもなく、インターネットに接続できる限られた研究者同士がメールを送り合っていた時代です。そんなときに策定されたのが、 RFC724[1] です。これは現在(執筆時点)最新のメールアドレスなどについて定めたRFC5322(Internet Message Format)の遠い祖先で、1977年に制定されています。端的に言うと、これの「負債」が今に残っていると考えるとわかりやすいです。 その結果、以下のようなメールアドレスはRFC上有効ということになってい
XMLのデータの中に @attributes という要素が出てくる場合があります。通常の要素の取得方法と異なった取得方法になりますので注意が必要です。 はじめに simplexml_load_file関数でXMLデータを読み込みます。 $xml=’ファイル名’; $data=simplexml_load_file($xml); $dataの中身は以下のようなオブジェクト(配列)になっています。 SimpleXMLElement Object ( [Element] => Array ( [0] => SimpleXMLElement Object ( [@attributes] => Array ( [Name] => Taro ) ) [1] => SimpleXMLElement Object ( [@attributes] => Array ( [Name] => Jiro ) )
ページごと、あるいはディレクトリごとにベーシック認証をかけたい時に、.htaccessでの設定よりもPHPでやった方が簡単だと思います。 以下のやり方で、PHPでのベーシック認証と、私が体験したエラーと対策を記録します。 認証画面の表示と入力の受取り、そして照合 記述する手順は以下の通りです。 もしユーザーとパスの入力が、指定の文字でない場合、認証画面を表示させ、 指定の文字であった場合、htmlの内容を表示させる。 ソースコードにすると下記のようになります。 if($_SERVER['PHP_AUTH_USER']!=="user" || $_SERVER['PHP_AUTH_PW']!=="password"){ header("www-Authenticate: Basic realm=\"This Page is Member Only\""); header("HTTP/1.0
はじめに 私は個人開発で一山当てたいと常々思っていて、そのためにいくつかヒットしそうなサービスのアイデアがあります。エンジニアであればアイデアを具現化することに躊躇してはいけないと思うわけですが、一度リリースしてしまうとランニングコストが発生するわけで、仮に全く人気がでなかったとしたらランニングコスト分の赤字を垂れ流すことになります。 一方、個人開発者というのはおそらく誰しも夢見がちなので、リリース後バズったりしてユーザーが大量に押し寄せてきてしまってサーバーダウンする可能性も考えてしまいます。 その結果、「全く誰も来なくてランニングコストが赤字になったらどうしよう」という不安と「めちゃくちゃバズってしまってサーバーダウンしてチャンスを逃したらどうしよう」という不安が、心の中でせめぎ合うことになります。 そこで、今回はその2つの不安を一気に解消する「使われなければランニングコストが限りなく
問題 phpで文字列を暗号化して、元の文字列に戻せますか。 答え ハッシュを生成するのではなくて(md5,sha)、暗号化、復号化をする場合はMcrypt関数が使える。OpenSSL関数もいいらしい。 Mcrypt関数 mcrypt_cbcやmcrypt_cfbではなく、暗号化に mcrypt_generic()、復号化にmdecrypt_generic() を使えとのことなので、そのようにしてみる。 <?php /* データ */ $key = '長い鍵長い鍵長い鍵長い鍵長い鍵長い鍵長い鍵長い鍵長い鍵長い鍵'; $plain_text = '暗号化したいデータ'; /* モジュールをオープンし、IV を作成 */ $td = mcrypt_module_open('des', '', 'ecb', ''); $key = substr($key, 0, mcrypt_enc_get_ke
ここは、技術情報、身の回りに起こった出来事を、「もしかしたらみんなの役に立つかもしれない」と思って書き留めておく場所です。 最近またPHPを色々使いだしまして その中でPDFも作ったので書き残しておこうと思いました。 mPDFとは mPDFはPHP製のPDF作成ライブラリです。 といっても難しい作り方ではなく、HTMLを記述すればPDFを作成してくれるという、とんでもなく便利なライブラリなのです。 インストール composerを使用します。 composer require mpdf/mpdf インストールにはgdが必要です。 今回はインストールされた最新のバージョンv8.0.7を使用しています。 v7以上では機能的な違いがあまりないようです。 とりあえず使う <?php declare(strict_types=1); require __DIR__ . '/vendor/autolo
上記で表示されている画像ですが、HTMLのコードは、このように記載しました。 <html> <head> <meta charset="utf-8" /> <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/css/bootstrap.min.css" integrity="sha384-Gn5384xqQ1aoWXA+058RXPxPg6fy4IWvTNh0E263XmFcJlSAwiGgFAW/dAiS6JXm" crossorigin="anonymous"> </head> <body> <nav class="navbar navbar-dark bg-primary"> <a class="navbar-brand" href="#">reCapture v2 Test</a>
だけでセッションを利用していませんか?もし、この一行だけでsessionを使用しているのなら、直ちに変更したほうがいいでしょう。 どこが危ないのか セッションの仕組みをもう一度確認してみましょう。 まず、サーバーが初アクセスのプレイヤーにクッキーでIDを作成し保存します。 そのあと、セッションIDをアクセス毎に確認し、保存データからHTML等を生成します。 ここで注意する点が、Cookieでsessionidを保存するということです。 Cookieとは、クライアント側で変更可能(ほとんどのブラウザで可能)なため、友人のsessionidを盗めばログインもできてしまいますし保存データもすべてアクセスできてしまいます。 つまり、ほとんどのサイトがsessionにログインデータを保存しているので、ユーザーを識別するためのsessinidが盗まれてしまえば保存されているデータも盗まれるということに
前回は、こちらの記事でDocker + WordPress + Xdebugな環境を作りました。 今回は、そこからさらにPhpStormでステップデバッグを実行できるようにしていきます。 Docker + WordPress + Xdebugの準備 はじめに、前回のDockerfileに少し手を加え、Xdebugの設定ファイルを利用できるようにします。なお、今回からはdocker-composeを利用していきますので、まずはディレクトリ構造を下記のように準備してください。PhpStormでプロジェクトを作成し、以下のようにファイルとディレクトリを用意します。 続いてxdebug.iniの中身です。 #xdebug.ini zend_extension=xdebug # Xdebugをどのモードで動かすか? # ※これはプロセス起動時のみ設定可能なのでここでしか指定できません。 # 初期値は
reCAPTCHA v3 とは、クローラーやロボットによるアクセスを制限して、無駄にサイトアクセスさせないために設置する認証装置です。 主に、連投されては困るようなコンタクトフォームや、コメント投稿、ユーザー登録などの画面に設置して、そのボタンを押すのが人間なのかどうかを判定します。人間でないと判断した場合は、エラーを出すなどして実行できないようにします。 v2 までは、画像などの認証でしたが、v3からは、ページにおけるユーザーの動きを見て、その判定を自動で行うので、ユーザーにとっては何も行う必要もなく負担をかけることもありません。 Ajax を使って reCAPTCHA 認証する 書いてみると意外と簡単ですが、これを行うには、reCAPTCHA 自体の仕様というか、全体の動きを把握してないとコードに落とし込みにくいと思います。 認証が必要なページにGoogle指定のJavaScriptフ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く