遷移先として設定したいLightningコンポーネントの、aura:component
タグのimplements
にlightning:actionOverride
をつける。
1
|
|
こうすれば、コンポーネントの選択肢として現れるようになる。
ただし上書きされたアクションは、モーダル表示ではなく、常にページ遷移となる。
さらに、編集ボタンを押下した際にはそのレコードのIDを持った状態で遷移するが、それを取得するには、implements
に、force:hasRecordId
を付与し、さらに、force:recordData
タグを使用してIDを渡してやる必要がある。
1 2 |
|
すると、JSコントローラの中で以下のようにIDを取得することが可能。
1
|
|
オブジェクトマネージャから、設定したいオブジェクトの、「ボタン、リンク、およびアクション」を開き、設定したいボタンを編集することで変更可能。
入れ方は公式の通り。
どこか適切な場所にリポジトリをクローンし、それを読み込んで利用する。
1
|
|
.zshrc
ファイルに以下の設定を追記する。
1 2 3 4 5 6 |
|
ターミナルを再起動。
$ sfdx forc
などと打って、タブを押すとforce
、sfdx force:
の後にタブを打つと設定されているコマンドの一覧がリストで表示されたりするようになる。
サイトで使用される権限は、設定した各サイト別にユーザが作られ、そのプロファイルで変更が可能。
作成したカスタムオブジェクトはデフォルトでは作成権限はないため、権限を与えてやる必要がある。
そのプロファイルへアクセスするには…、
設定から、クイック検索に サイト
と入力。
表示されるメニューから、サイト
をクリック。
サイト一覧から変更したいサイトの「表示ラベル」をクリック。
詳細が表示されるので、「公開アクセス設定」をクリック。
ここから通常のプロファイルと同じように権限を変更してやることが可能。
オブジェクトへのアクセス権限を編集したい場合は、「オブジェクト設定」から変更してやる。
ここから設定したいオブジェクトを選択し、オブジェクト権限、や、項目権限、を与えてやればよい。
しかし、上記の手順で、作成、権限を与えているにも関わらず、下記のエラーが出た。
DML operation INSERT not allowed on YOUROBJECT__c
色々確認していると、オブジェクトを公開していなかったから、だった。
カスタムオブジェクトの項目で、オブジェクトのリリース状況
という設定があるのだが、これが開発中
になっていたため、外部扱いとなるサイトからはインサートが出来なかったよう。
これをリリース済み
に変更すると、無事、インサートが可能となった。
ポータルユーザとして登録しようとすると、対象のユーザには必ず取引先責任者が紐付いていなければならないよう。
指定せずに有効化しようとすると以下のようにエラーが出てしまう。
取引先責任者のないポータルユーザは作成できません
しかし個人取引先が有効になっている場合には取引先責任者は使用しないのでどれを指定すればいいのかわからず迷ってしまった。
個人取引先を有効にしている組織の場合、取引先(Account
)を作成すると取引先責任者(Contact
)が自動的に作成されるよう。
SF上では取引先しか見えていないのだが、Contact
でクエリを実行して検索すると、同じ名前のレコードがヒットする。
よって、取引先を作成し、同時に作成される取引先責任者を検索しそれをユーザと紐付けてから、ポータルユーザとして登録してやることで無事、作成することが出来た。
手順としては以下。
Account
)を作成Contact
)を取得User
)を作成実際のコードは以下。
ユーザを作成する際のプロフィールは作成済のポータルユーザ用のプロフィールを指定すること。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
|
datetime
)型のデータをVisualforceに表示する時に、apex:outputtext
を使用すればフォーマットさせて表示することが出来るのだが、GMTで表示されてしまうため9時間ずれてしまう。
これはオプションでは用意されていないようで、apex側でずらす時間を指定してそれを足してやる、という方法でタイムゾーンを指定してやる必要があるよう。
apexで使用アカウントでセットされているタイムゾーンを取得してずれている時間のミリ秒を取得してそれを足す、という方法。
1 2 3 4 5 6 7 8 |
|
1 2 3 4 5 6 7 8 9 10 11 12 |
|
post_updated
のアクションフックの引数に更新前後のでデータが渡されてくるので、そこから取得できるよう。
これを使えば比較可能。
例えば、スラッグが変更された時に処理をする場合は以下のようになる。
1 2 3 4 5 |
|
Salesforce公式が出している、JetBrainsのエディタのプラグイン。
Illuminated Cloud 2 :: JetBrains Plugin Repository
補完もちゃんと出るし、テストやdeployも可能っぽい。
以下、英語だけどデモ動画。
以下の2つのエディタで利用可能
IntelliJ IDEAのCommunity Editionなら無料で使用可能。
30日間は無料トライアルがあるが、それ以降は、$125/年、のサブスクリプションプランとなっている。
Preferencesから、Pluginsを選択し、Browse repositories…を選択。
検索に、Illu
などと入力して、結果の、Illuminated Cloud 2
を選択してインストールする。
(Illuminated Cloud
無印の方は古い方なので間違えないように)
New Projectを選択し、Illuminated Cloudを選択。
Connectionの部分で接続するSalesforceのアカウントを選択する。
まずはアカウントの設定が必要なので、鉛筆マークからアカウント情報を追加すする。
入力して、Testボタンで接続テストが可能。Connection configuration is valid.と表示されればOK。
(TestせずにOKをクリックすると接続確認してからでないと接続出来ない、等の警告が出た)
OKをクリックすると、メタデータが取得され、どれを同期するかのリストが表示されるので、ApexやVFなど必要なものを選択してNextをクリック。
プロジェクトの保存先を聞かれるので選択。
作成されると、以下のアラートが表示された。
MavensMateなんかと同じく、保存アクション(コマンド+S)時にSFへDeployするかどうか、のよう。
ファイルの保存自体は自動で行われるので、deployしたい場合にのみ、コマンド+Sする、という流れになりそう。
Yesで有効化しておく。
FAQとして、メニューのショートカットの一覧?が載っていた。
FAQ – Illuminated Cloud
新規作成はFile→Newで作成可能。
src/classes
を選択した状態ではApex Class
が、src/pages
を選択した状態だと、Visualforce Page
が選択肢に表示される。
SF側の更新を聞かれるので、Yesで。
作成するとSFの方にもそのまま作成される。
ファイルを右クリックでDeleteを選択。いくつか聞かれるが、Yesを選んでいけば、SF上のファイルも削除される。
SF側で作成や削除したファイルがあれば、Retrievalから同期が可能。
新しく追加したい時は、Searver Onlyにチェックし、 Retrieve for Merge
をクリックする。
すると、マージするファイルの選択画面となるので、選択し、緑の三角をクリックして選択しているファイルをマージさせる。
(この場合は2ファイル追加)
Run → Runを選択。(Ctrl + Opt + R)
Edit Configurations..というウインドウが出るのでそのままクリック。
左のツリーから、Apex Unit Testsを選択。
Test Classesからテストしたいクラスを選択。
そのままRunをクリックすればテストが実行される。
結果は以下のような感じ。
Eclipseの時と違って特に悩むようなところはなかった。
ただ、この機能ってどこにあるんだろう?となった時に探す手段がない。
公式のドキュメントもそれらしいものがほぼないし。
とはいえ、公式で有料のものなので今後のサポートなどは安心感がある。Salesforce DXも対応しており、今後はこれ一択、とかになりそうな気配。
S3互換のオブジェクトストレージ環境。今回はVagrant上のCentOS7にいれた。
入れかたはまんま以下を参考に。
インストールはダウンロードして配置するだけ。
1 2 3 4 |
|
オブジェクト保存先のディレクトリを作成してユーザを指定する。
1 2 |
|
/etc/default/minio
に設定ファイルを作成して記述。
アクセスキーとシークレットは後でログインや接続などに使用する。適当な値を入れておく。
1 2 3 4 5 6 7 8 9 10 11 |
|
自動起動設定と起動。
1 2 |
|
ブラウザからアクセス出来るGUIが用意されている。
Vagrant経由でのアクセスは、Vagrantで指定しているIPに9000ポート(デフォルト。指定したポートで)でアクセスすると確認出来る。(httpなので注意)
例) http://192.168.33.33:9000/
画面右下にあるプラスボタンからバケットを作成出来る。
ここからファイルを直接アップすることも可能。
バケットは適当に作っておく。
以下を参考にさせてもらった。
laravelから保存してみる。
基本的には環境の設定を渡してやるだけで動作する。
S3への保存をさせるのと、Formヘルパーを使ったのでそれぞれのパッケージを入れた。
1 2 |
|
filesystems.php
でドライバーの設定をする。
S3の場合と微妙に違うため、minio
用として分けておく方がよいと思われる。
config/filesystems.php
1 2 3 4 5 6 7 8 9 |
|
デフォルトのS3用の設定は以下のようになっている。
デフォルトの設定
.env
ファイルで値を設定する。
1 2 3 4 5 6 |
|
FILESYSTEM_DRIVER
: 設定したminioを指定MINIO_ENDPOINT
: vagrantの内部からアクセスすることになるので、ローカルホストにポート番号をつけた形で指定するAWS_KEY
: 設定した値AWS_SECRET
: 設定した値AWS_REGION
: なんでもよいAWS_BUCKET
: 作ったバケットこれであとは普通にs3に投げる方法で実装してやるだけでOK。
以下のような感じで作って試してみた。
ビュー (抜粋)
1 2 3 4 |
|
コントローラー (抜粋)
1 2 3 4 5 6 7 8 9 10 |
|
アップしたものがGUIで確認出来たり、s3互換ということで、aws-cliが使えたりするらしく、がっつりテストしたりするなら便利かもしれない。
とはいえ、Laravelでの開発となると、ストレージにlocalを指定してやっても処理部分は全く同じ書き方で対応が出来るため、わざわざストレージを立ち上げてまでやる必要はないかもしれない…。
alter
してもいいけど、ちゃんとマイグレーションファイルも動くか確認したい。パッケージでよしなにバックアップ取ったりしてくれるものはあるようだけど、postgreSQLのものが多かったり、そのためにパッケージインストールするのも、、と思ってしまう。
それならコマンドで叩いたほうが早い、というわけで、備忘録。
テーブル情報を抜いたデータ情報のみをエクスポート。
(作業はvagrant内に入った状態で)
1
|
|
エクスポートされたデータから、migrations
テーブルのインサート情報の部分だけは削除しておくこと。
(laravelのmigrateで自動作成されるので、インポート時にID重複のエラーが出る)
1 2 3 4 5 |
|
Laravelに用意されている。
1
|
|
あとはインポートするだけ。
1
|
|
完了。
クッキーをセットするには以下のようにする。
ページに対してクッキーを作成する形のよう?
1 2 |
|
Cookie
クラスのコンストラクタは以下の通り。
第4引数の秒は、-1
を指定するとブラウザうを閉じるまで、
0
を指定すると削除、となる。
よって、削除したい場合は以下のように同じ値で0病にセットするとよい。
1 2 |
|
取得は以下のように。
1 2 |
|
getValue()
でセットされている値を取得することになる。
RequireAny
とかを使った方法になっているよう。基本は、以下の3つのタグで囲って条件付けしていく。
RequireAny
– どれか一つでも当てはまれば許可RequireAll
– 全てに当てはまれば許可RequireNone
– どれか一つでも当てはまれば拒否デフォルト、何も囲わなければ RequireAny
となるよう。
1 2 3 4 |
|
1 2 3 4 5 6 7 8 9 10 11 |
|
env
で変数的に値を設定出来る。
以下みたいな感じ。
SetEnvIf {種類} {値} {変数名}
1 2 3 4 5 6 7 |
|
正規表現を使わない場合は正しくかかないと無視されてしまう部分があった。
例えば、/api/
以下のディレクトリを許可したい場合。
SetEnvIf Request_URI xxx valid-url
ここの、xxx
に入るものを色々変えてアクセスしてみた。
(api/test.php
に対してのアクセス結果)
/api/*
/api/
/
/a
/test/
/test
/t
/t/
"^/api/*"
"^/api"
"^/a"
"^/test/"
"^/t"
正規表現を利用すると意図した通り動いているが、正規表現を利用しない場合には、スラッシュの後の文字列は無視されているような挙動をしている。/api
でも/test
でも/
と同じ。注意が必要。
ベーシック認証の設定などは以下。
1 2 3 |
|
で、認証されたユーザを許可、は以下を記述。
1
|
|
で、これらを組み合わせて設定した制御をかけていく。
例えば…
ベーシック認証をかけるが、特定のIPは許可。さらに特定のディレクトリは常に許可する、とかの場合
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
RequireAny
の条件なのでいずれかに合致すればアクセスが許可される。
URIの指定は正規表現を使っておいた方が確実。
Laravelで同じようにURIを利用して制御したい場合は、制御対象のURIだけを許可してやるだけではダメだった。
理由はルーティングの仕組みにあって、Laravelの場合はアクセスされた際に一旦、index.php
にリダイレクトさせてからLaravelを起動し、ルーティングをさせる仕組みになっている。
よって、/index.php
を許可しておいてやらないと認証が通らなくなってしまう。
1 2 3 4 5 6 7 8 |
|
ただしこの方法だと、/index.php
への直接のアクセス(トップページ)は許可されてしまうので注意。
(とはいえ、読み込んでいる別ディレクトリのcssやjsや画像なんかは拒否される)
(/
へのアクセスは拒否される。)
SetEnvIf
で指定出来る要素は以下にドキュメントがあった。
mod_setenvif – Apache HTTP サーバ バージョン 2.4
SetEnvIf ディレクティブ
のセクション
created_at
とupdated_at
を更新してくれる。updated_at
カラムがないテーブルを利用したかったのでその方法。
Eloquentモデル内で定数を使用することで明示的にカラム名を指定する事が可能。
1 2 |
|
これを利用し、更新カラムはない事を指定してやればよい。
1
|
|
これだけ。
ちなみに、created_at
、updated_at
を自動で更新させたくない場合は以下のように指定してやればよいよう。
自動で更新しなくなるので、それらのカラムがないテーブルでもEloquentモデルを利用出来るようになる。
1
|
|
Herokuのビルドパックには heroku/nodejs
とheroku/php
を入れておき、順番はnode.jsが先。
1 2 3 4 |
|
この状態でpushしてデプロイするも、npmのインストールなどは走るがLaravel Mixのコンパイルが走らない状態(たぶん)。
ビルドログを見ると以下のようなエラーが出ている。
1 2 3 |
|
依存関係が解消出来てないとかなんとか?
ググると以下の情報。
環境変数に、YARN_PRODUCTION
をfalse
で追加してやるだけ。
環境変数を追加してやることで、devDependencies
から依存関係を取得するように指示してやる事が出来るよう。
First, set
YARN_PRODUCTION
to false using the following command. This tells Heroku to install the devDependencies in your package.json, but leaves NODE_ENV as production.
Google翻訳
まず、次のコマンドを使用して
YARN_PRODUCTION
をfalseに設定します。これは、あなたのpackage.jsonにdevDependenciesをインストールするようにHerokuに指示しますが、NODE_ENVをプロダクションとして残します。
記事の通り、上手く行ってなかった環境に環境変数を追加してやると無事、コンパイルされるようになった。
]]>LaravelではデフォルトではPOST通信には全てCSRFトークンをつけてやる必要がある。
ajaxでの通信でも例外ではない。
なので、そのまま何も考えずにajaxを使うとそこで引っかかってしまう。
方法としては(主に)2つ。
もちろん後者の方が安全。
HTMLのmetaタグにCSRFトークンをおいてやり、それを取得して送る。
POST送信の_token
パラメータに入れてやるだけでよい。
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
公式のドキュメントにも方法は載っているが、これは、Axios HTTPライブラリを使った方法?のよう。
上記でないと上手く動作しなかったが…やり方が悪いのかもしれない。
一応、トークンの対象外とする方法も。
app/http/Middleware/VerifyCsrfToken.php
内にて指定してやる。
1 2 3 |
|
今までは、返却用するJSON用のクラスを作成し、そのクラスを返却していたのだが、
そもそも返却の方法としてはそれが正しくなかった(お作法に則っていなかった)よう。
[salesforce]Apex REST作成時のtips
この辺の記事内で返却しているやり方。
実際には、return
で結果を返す必要はなく、RestResponse
クラスに追加してやるだけでよかった。
ステータスコードの指定は以下のようにする。
1 2 |
|
デフォルトの情報だと、Content-Type
がapplication/octetstream
になっているようなので、application/json
に変更したい。
ヘッダ情報の追加・変更は以下のようにする。
1 2 |
|
レスポンスの内容をJSONで返す場合、作成した返却用クラスをJSONにパースし、Blob
にキャストして追加してやる。
1 2 3 4 |
|
上記をまとめると以下のような形になる。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
|
エラー発生時にはステータスコードが400
で以下のようなJSONが返却される。
1 2 3 4 5 6 |
|
テストクラスを書く際に、送信結果を取得する場合には以下のようにする。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
Table name
にはテーブル名を入れる。
(何も入れなかった場合はダミーの文字が入る)
CSV Format Text
にはカンマと改行区切りのCSVフォーマットのテキストを入力する。
convert
ボタンを押すと、その下のテキストエリアに出力結果が表示される。
コードはGithubにあげた。
https://github.com/k-usk/laravel-csv-seeder
無駄にHeroku Buttonも付けたので自分の環境で動かしたいという人がいたらどうぞ。
CSVを読み込んで整形してるだけなんでたいしたことはしてない。
CSVの整形には以下のライブラリを使用した。
同じようなツールがないか調べたりはしたのだが、CSVをそのままSeederとして使えるものはいくつかあった。
後は、エクセルファイルをLaravelで扱うための便利パッケージとか。
エクセルを作ったりそのまま読み込めたりするよう。これはこれでかなり有用そう。
ただし今回はそこまでのツールではなく、また、アプリ本体にそういう機能は組み込みたくなかったため、別のツールとして作成した。
Request
の isSecure
が正しく動作してくれなかったのでメモ。
ブレードでリンクを生成する時に、`と記述して組み立てていたのだが、ローカル環境では正しく
httpsのURLで絶対パスが指定されていたのに、herokuにアップした途端に
http`で生成されるようになってしまった。
Request
のroot()
がどうやって判定しているのかを辿っていくと、getScheme()
というRequestの関数内で、以下のように判定して取得していた。
1 2 3 4 |
|
よってこの、isSecure
が正しく動作していないと思われる。
Herokuはロードバランサが標準で入っているため、その辺りだろうとググってみると公式ドキュメントがヒット。
TLS/SSL証明を行うロードバランサの裏でアプリケーションが実行されている場合、アプリケーションが時々HTTPSリンクを生成しないことに、気づくでしょう。典型的な理由は、トラフィックがロードバランサにより80番ポートへフォワーディングされるため、セキュアなリンクを生成すべきだと判断できないからです。
まさにこの通りで、app/Http/Middleware/TrustProxies.php
で全てのプロキシを信用するようにしたところ、無事、https
で生成されるようになった。
1
|
|
]]>Amazon AWSや他の「クラウド」ロードバランサプロバイダを使用している場合は、実際のバランサのIPアドレスは分かりません。このような場合、全プロキシを信用するために、**を使います。
Laravel Passportをインストール。
1
|
|
Package Auto-Discovery に対応しているため、プロバイダに追加してやる作業は必要ない。
DBに必要なテーブルを作成する。
1
|
|
OAuth用に以下のテーブルが作成される。
oauth_access_tokens
oauth_auth_codes
oauth_clients
oauth_personal_access_clients
oauth_refresh_tokens
トークン作成時に使用されるキーを生成する。
1
|
|
キーは、/storage/
以下に生成される。
デフォルトでは.gitignore
で無視する設定となっているので注意。
また、公開リポジトリにアップしてはいけない。
対処法などは以下参考。
また、キーの生成とともに、DBにクライアントが作成される。
1 2 3 4 5 6 7 |
|
一つ目が、 Laravel Personal Access Client
二つ目が、Laravel Password Grant Client
二つ目はユーザ名+パスワードを利用したアクセストークンの発行に利用出来る。
(ユーザーとの紐付けは特に必要なし)
(必要なければ消しておいてもよい)
AuthServiceProvider.php
に追加/app/Providers/AuthServiceProvider.php
1 2 3 4 5 6 |
|
auth.php
のdriverをpassportに変更/config/auth.php
1 2 3 4 5 6 7 8 9 10 11 |
|
冒頭の趣旨を実現するために、マシン-マシン間の認証に最適、という認証方式を採用する。
Kanel.php
に追加/app/Http/Kanel.php
1 2 3 4 |
|
以下にアクセスして取得出来る。
・リクエスト
1
|
|
項目 | 内容 | |
---|---|---|
grant_type |
client_credentials | |
|
client_id |
発行したクライアントのID(数字) | | |
client_secret |
発行したクライアントのシークレット | | |
scope |
アクセスするスコープ | |
・レスポンス
1 2 3 4 5 |
|
発行されたトークンは、oauth_access_tokens
テーブルに格納されていく。
デフォルトではトークンの有効期限は1年間となっている。
変更するには、AuthServiceProvider
のboot
メソッドから変更可能。
/app/Providers/AuthServiceProvider.php
1 2 3 4 5 6 7 8 |
|
上記トークンを使用してアクセス制限をかけたAPIへアクセスする。
追加したミドルウェアを使用して、apiのルートにこの認証で使用するエンドポイントのリクエストを追加。
/routes/api.php
1 2 3 |
|
apiのルーティングは、/api
以下に作成される。
よって、エンドポイントは以下になる
1
|
|
ヘッダにアクセストークンを付与してアクセスする。
Bearer YOUR-ACCESS-TOKEN
アクセストークンが間違っているなどの場合は、InvalidArgumentException
が発生する。
Proximoは一番下のプランでも$5/月かかる有料アドオンとなっている。
以前の記事ではCURLで接続していたが、今回はGuzzleを使って接続してみる。
ドキュメントを確認すると、以下の方法でプロキシを指定可能、とのこと。
http://docs.guzzlephp.org/en/stable/request-options.html#proxy
1
|
|
ProximoをHerokuに追加すると、環境変数に自動的にプロキシのURLが追加される。
1
|
|
上記URL内の、xx-xxx-x-xxx
の部分の数字が固定IPとなる。
(ダッシュボードからも確認可)
これをそのままproxyのURLとして指定してやればOK…だと思ったのだが、エラーが出てしまった。
cURL error 56: Proxy CONNECT aborted
QuotaGuard Staticのアドオンを追加した際に取得出来るURLを同じように指定してやったところ、問題なくアクセス出来たので、Guzzleは悪くなさそう。
ProximoだとURLをパースしたりとかが必要なのか…など悩んでいて、URLを見比べていると、ProximoのURLにはポート番号がついてないことに気付く。
改めてドキュメントを確認してみると、ポート番号は80
で固定、とのこと。
If you’d rather use Proximo as a standard HTTP proxy, use PROXIMO_URL on port 80.
https://devcenter.heroku.com/articles/proximo#using-the-proximo-http-proxy
よって、環境変数に追加されたURLの最後に :80
とポート番号を追加してやると、無事、アクセスすることが出来た。
1 2 3 4 5 6 |
|
Proximoの固定IPがJSON内に返ってきたらOK。
ポート番号がデフォルトでは入っていないため、少しハマってしまった。
どうやらさくらのサーバはかなりクセの強いことで有名らしく、以下のような普通の?https強制のコードだとリダイレクトループとなってしまう。
1 2 3 |
|
ロードバランサを使っている場合はHTTPS
がon
にならないため、ずっとoffの状態になりリダイレクトループが起こる。
よって、以下のように書く。
1 2 3 |
|
しかしさくらの場合は特殊なようで、以下ような挙動になっているよう。
%{SERVER_PORT}
には常に80
が設定されている%{ENV:HTTPS}
にはON
、%{HTTP:X-Sakura-Forwarded-For}
にはリクエスト元のIPが設定されるよってhttpsでない判定の場合は、%{ENV:HTTPS}
がonではない、%{HTTP:X-Sakura-Forwarded-For}
は空、の場合はリダイレクト、という判定にすればよいよう。
よって以下となる。
1 2 3 4 |
|
ベーシックをかける際に、そのままベタで書いてしまうとhttpsへリダイレクトさせている関係上、httpでベーシック認証、httpsでベーシック認証、と2回聞かれることになってしまう。
これをhttpsでのアクセス時にのみ有効としたいので、上記のさくらサーバの特性を活かして、%{HTTP:X-Sakura-Forwarded-For}
が空でない場合にのみ、ベーシックを有効とするようにした。
(%{ENV:HTTPS}
は、ケースによってはon
にならない場合もあるよう)
1 2 3 4 5 6 |
|