2017-10-04

GAEでのSSL証明書の更新で「閲覧権限が無い」というエラーが出る場合の解決法

Google App Engine(GAE)で運用しているサイトがあって、そのSSL証明書の期限が切れそうになったので更新しようと思ったらエラーが出てはまりました。

検索しても全然情報が出てこなくてかなり苦労したけど、何とか解決できたので一応書いておきます。

SSL証明書はLet's Encryptを使っています。

Google Cloud Platformの管理画面に入って、App Engineの部分で新しい証明書をアップロードしようとすると「このページを閲覧する権限がありません。」という趣旨のエラーが出て何度やっても証明書の更新ができませんでした。

日本語で表示されたエラーの文言をそのままコピペして検索しても、ほとんど出てこなかったので、言語の設定を英語に変更して同じことをして英語のエラーを表示させました。

すると以下のようなエラーが出ました。

「You do not have sufficient permissions to view this page」

この英語の文言はそのままですが、さきほどの日本語のエラーは残しておくのを忘れてたので正確ではありません。

英語で表示されたエラーをそのままコピペして検索すると、同じエラーで困っているというのをいくつか見つけました。

こういう時に、つくづく日本語の弱さを感じますね。やっぱり英語は絶対にできた方がいい。

それで、解決のきっかけになったの情報がgcloudを使ってSSL証明書をアップロードすると、より詳細なエラーの内容が表示されるということでした。

その人が出たエラーは、証明書を発行する時にwwwの部分をワイルドカード(*)にしてたのがダメだったみたいな内容でした。

私は、出て来たエラーが、ページの閲覧権限が無いというような内容だったので、てっきり管理画面にログインしているアカウントの問題だと思ってました。

管理者権限でログインしているのに閲覧権限が無いというのがどうしても腑に落ちなかったのですが、どうやらそういうことでは無いということがわかったので、別の方法をいろいろと試して見ました。

最終的に解決できたのは、ドメインのDNSの設定をやり直したことでした。

もう一度全く同じドメインをカスタムドメインに追加して設定するところから始めたのですが、ドメインの所有権を確認するために指定されたとおりに、TXT、CNAMEの追加をしても全然確認が取れませんでした。

そこで、同じようにGAEでうまく動いている別のドメインのDNS設定を見てみると、AAAAの部分にも4つ設定がありました。

今回エラーが出ているドメインにはAAAAの設定をしてなかったので、それを追加して見ました。

  • AAAA / @ / 2001:4860:4802:32::15 / 1時間
  • AAAA / @ / 2001:4860:4802:34::15 / 1時間
  • AAAA / @ / 2001:4860:4802:38::15 / 1時間
  • AAAA / @ / 2001:4860:4802:36::15 / 1時間

これを追加すると、すぐにドメインの所有権の確認が取れました。

さらに、SSL証明書のアップロードも無事にすることができました。

今まで、AAAAの設定をしてなかったのに、どうして何事もなく動いていたのか分からないし、前にSSL証明書のアップロードをした時には今回のようなエラーも出ずに問題なくできました。

よく分借りませんが、何とか解決できたので、もし、同じような症状でエラーが出た人がいれば参考にしてみて下さい。

2017-07-20

iPadをメインマシンとしてWEBサイトを作成・更新できるか?

私はiPadが大好きなのでもちろんiPad Proの2017年モデルも買いました。

ちょっと意外に思われるかもしれませんが、サイズは10.5インチではなくて12.9インチを買いました。

以前は9.7インチのiPadを使っていたのですが、Apple Pencilが出てからは、完全にiPadがデジタル教科書、デジタルノートと化してしまって、線を引いたり書き込みをしながら本を読んだり、勉強をしたりするのにほとんどiPadしか使わなくなりました。

紙の本とかノートを使うことが本当になくなって、限りなく100%に近いくらいペーパーレスを実現することができています。

単に本を読むとかウェブサイトを見るとか映画を見るとかビューアとして使うだけなら9.7インチとか10.5インチでも十分なんですけど、デジタル教科書、デジタルノートとして使うとか、何らかの作業をするとなると断然12.9インチが使いやすいです。

特にスプリットビューを使った時に12.9インチの恩恵を受けることができます。

新しいiPad Pro 12.9インチを使ってみて感じるのはiPadをメインマシンとして使えるようになってきているということです。

2017年がMacBookとかノートPCが本格的に消えていくスタートになるような気がします。

iOS11ではファイラーアプリのFilesが実装されるらしいので、iOS11が使えるようになる2017年の秋が楽しみです。

本格的にiPad Proをメインマシンとして使っていくために、ウェブサイト(ホームページ)の制作、更新、管理をできるだけiPad Proでやってみようと考えて試行錯誤しています。

いろいろやり方を考えたのですが、現状でかなり満足できる環境が整ってきたので、私なりのやり方を紹介させていただきますので、興味のある人は参考にして下さい。

結論から言うと、iPad Pro、Smart Keyboard、Apple Pencilといくつかのアプリがあれば、iPad Proはウェブサイトを制作するためのメインマシンになります。

私の場合、iPadだけでサイトを制作したり更新したりするわけではなくて、メインで使っているiMacやサブマシンとして使っているMacBook Proも使っているので、ローカルのデータの整合性を取るためにそれらのマシンでローカルデータを共有する必要があります。

iPadを使う前はiMacとMacBook Proだけだったので、いろんなデータを入れているAppleのAirMac Time Cupsuleにデータを保存してそこに両方のマシンからアクセスしていました。

具体的に言うとソフトはDreamweaverを使っているので、ローカルサイトフォルダーをAirMac Time Cupsuleのそれぞれのフォルダに設定していました。

iPadで使うhtmlエディタは1,200円で販売されているTextasticというアプリを使っているのですが、そのアプリからは残念ながらAirMac Time Cupsuleに接続できませんので(もしかしたらできるのかもしれませんが、私はやり方が分かりません)、そのやり方ではローカルデータをiPadで共有することができません。

となると、iPadでローカルデータを変更した場合にその続きの作業を別のiMacなどでやろうとするとかなりめんどくさいことになってしまいます。

なので別の方法を取らないといけないのですが、幸いにもTextasticはデフォルトでiCloudをローカルデータに設定することができるようになっているのでそれを使ってやってみることにしました。

iCloudは無料だと5Gまでしか使えなくて全然足りないので、月額130円を払って50Gに容量を増やしました。

月額130円で50G使えて、ウェブサイトのローカルデータをiPadを含めた複数マシンで共有できるのだったら安いと思います。

容量を増やしたところで、AirMac Time Cupsuleに保存していたサイトのデータを全部iCloudのTextasticのフォルダーに全部移しました。

そしてiMacとMacBook ProのDreamweaverのローカルフォルダも全部iCloudの方に変更しました。

これでiCloudをウェブサイトのローカルデータの保存場所としてiMac、MacBook Pro、iPad Proの全てで共有することができましたので、どのマシンからデータを変更しても全てのマシンに反映されます。

Textasticは(S)FTP接続にも対応していますのでhtmlやcssを変更した後で、サーバーにアップロードすることもできますし反対にダウンロードすることもできます。

これでかなり快適にiPad Proだけでもウェブサイトの制作、更新、管理ができます。

今、この記事を読んでいてiPadでウェブサイトを作ってやろうと考えているような人にはFTPの設定とかアプリの細かい使い方の説明なんて要らないと思うのでそういう細かい事はあえて省略させていただきます。

また、私はPythonをメインに使っていますが、iPadでPythonを書く時はPythonistaというアプリを使っています。

iOS11でファイラーアプリが実装されればPythonistaで作ったスクリプトも簡単に連携させることができそうなので、そうなるとiPadだけでも本格的なWEBサイトの開発もできるようになりそうです。

ProcreateとApple Pencilでイラストとかを描いて、Pythonistaでスクリプトを作って、Textasticでhtmlとかcssをコーディングして、ファイラーアプリでそれらのデータを管理できるなんて事になれば、楽しくてiPadがますます手放せなくなるし、完全にメインマシンとして使えますよね。

むしろApple Pencilが使える事を考えるとiMacやMacBook ProなんかよりもiPad Proの方が優れているかもしれません。

これからiOS用のアプリがどんどん充実してくるでしょうし、たぶんタブレットがノートPCに完全に取って代わるという時代があと数年で来るような予感がします。

iCloudって今まで全然使ってなかったけど、めちゃくちゃ便利ですね。

iCloudをローカルデータの置き場所にしている事になってますけど、本当は全然ローカルじゃなくてどこかの遠いサーバーに保存されているんですよね。

なのに本当に自分のパソコンとかiPadにデータがあるように超高速にアクセスできます。

ちなみにTextasticはiPadだけでなくiPhoneでも利用できるので、Bluetoothキーボードを持ち歩けばiPhoneでもホームページを作ったり更新することができます。

2017-03-13

GAE(Python 2.7) + Django 1.5 + SSLのcron jobsで301エラー

独自ドメインを使ってGoogle App Engineで運用しているサイトがあって、cronがうまく動かずにかなりハマりました。なんとか解決できたので、私がやった解決法を書いておきます。

同じような症状でエラーが出ている人はあまりいないと思いますが、もし当てはまったら参考にして下さい。

環境はだいたい以下のとおり。

  • Google App Engine
  • Python 2.7
  • 独自ドメイン(カスタムドメイン)で運用
  • SSL対応
  • Django 1.5

設定はうまくできてるはずなのにcron jobsが起動すると失敗するという症状が出ました。

ブラウザで直接URLを入力すると問題なく動いているのに、cronで動かすとなぜか失敗になってしまいます。

ログを調べてみるとcronでのアクセスのHTTPステータスコードが301になっている。他方でブラウザでURLを入力してアクセスした場合には200になっている。

GAEのcron jobsは、HTTPステータスコードを200番台で返さないとエラーになるということは知ってたので、301が返ってきている以上は失敗するというのは分かります。

でも、なぜ301リダイレクトになるのかが全く分かりませんでした。

かなり苦労して分かった原因は、Djangoのsettings.pyのMIDDLEWARE_CLASSESに設定していたSSLRedirectの設定でした。

そんな設定をしてたのをすっかり忘れてたけど、グーグルが全てのサイトでSSL対応することを推奨し始めた数年前に自分で設定してたのです。

せっかくSSL対応したのだからセキュリティのためとSEOのためにhttpに来たアクセスを自動で全てhttpsに301リダイレクトするために、sslmiddlewareを設定していたのです。

参考URL

具体的にはDjangoのsettings.pyのこの部分です。


MIDDLEWARE_CLASSES = (
    .........
    .........
    'appname.middles.sslmiddleware.SSLRedirect',
)

cron.yamlにターゲットを設定をしてない場合、cronが起動するとデフォルトのバージョンのURLにアクセスが発生します。

このデフォルトのバージョンというのは、ログを見てみると独自ドメインで運用している場合でも、最初に与えられるドメインであるappspot.comの方です。

しかも、httpsではなく、httpの方にアクセスが発生します。

例えば、以下のような設定で独自ドメインを使っている場合。

  1. デフォルトのドメイン(http) -> http://appname.appspot.com/
  2. デフォルトのドメイン(https) -> https://appname.appspot.com/
  3. 独自ドメイン(http) -> http://www.appname.com/
  4. 独自ドメイン(https) -> https://www.appname.com/

1と2は最初にデフォルトで与えられるドメインで、httpでもhttpsでもどちらでもアクセスできるようになっていると思います。

私の場合はそれに独自ドメインを設定して、SSL対応しているので4を中心に運用しています。

先ほどのsslmiddlewareを使って、3のhttpへのアクセスを全て自動的に4のhttpsの方に301リダイレクトしていました。

この様な設定の状態の時にcronが起動すると、1の指定したパスにアクセスが発生します。

するとsslmiddlewareによって自動的に2のhttpsの方に301リダイレクトが発生してしまうのです。

これが原因で、cronが失敗していたのです。

これを解決するためには、cronで起動するパスに対してだけ301リダイレクトをさせないという設定をする必要があります。

urls.pyにcronで起動させるパスを記述して、新たに別のssl_urls.pyというファイル作って残りを全て分離してそちらに移しました。

そして、分離したssl_urls.pyをincludeで呼び出し、それに{'SSL':True}を設定しました。

これでcronで起動させるパスに対しては301リダイレクトが生じずに、それ以外のパスに対しては301リダイレクトが生じるという設定になります。

このように設定してようやくcronで動かしても200が返ってきて無事に動きました。

urls.pyはこんな感じです。


urlpatterns = patterns('',
    # Cron
    (r'^cron/example/$', cron_example),
    (r'^cron/........),
                       
    # SSL
    (r'^.*?', include(appname.ssl_urls), {'SSL':True}),
)

注意が必要なのは「r'^.*?',」の部分です。最後に$が要りません。最後に$をつけるとどこのパスにアクセスしてもトップページが表示されるというおかしな事になってしまいました。

結局、すごく簡単で単純な事が原因だったので、同じような失敗をしている人はほとんどいないと思いますが、参考にしてみて下さい。