カテゴリーアーカイブ TECH

村上 著者:村上

【Webサイト】PDFファイルの回転・圧縮・分割・結合が簡単にできるサイト「Smallpdf」

最近、よくPDFファイルを扱うことがあるのですが、その際に便利なサイトが、こちらの「Smallpdf」。

smallpdf.com – 無料Pの変換はこちらでどうぞ!DF
https://smallpdf.com/jp

タイトルにあるように、PDFを回転させたり、圧縮したり、複数枚のデータのPDFを1枚ずつに分割できたり、逆に複数のPDFを結合できるサイトです。
それ以外にも、PDFを画像ファイルに変換したり、PDFをエクセルやワードに変換したりもできます。

 

「Smallpdf」のサイトはこちらのようなレイアウト。

トップページにボタンがずらりと並んでおり、ここからやりたいことを選びます。
アイコンもシンプルだし、下に何ができる丘も簡潔に書いてあって分かりやすいですね。

そのうちの一つを選択してみるとこんな感じ。
画像は「PDFを回転」を選択した画面です。

中央に大きく、ファイルを選択するエリアがあります。
ローカルファイルだけではなく、DropboxGoogle Drive から選ぶこともできます。
ファイルを選択した後は、右回転・左回転のボタンが表示されるので、任意の回転をかけた後「変更を保存する」ボタンを押します。
すると下の画像のようなファイルダウンロードページに移動するので、ここから PDFのダウンロードをします。

また、ダウンロード以外にも、Dropbox や Google Drive へ保存したり、もしくはさらにここからワードに変換したり、作成したPDFをパスワードで保護することもできます。
さらに変換したい場合、一度トップページに戻らなくて済むのは楽ですね!

 

ということで、ブックマークしておくと何かと便利な「Smallpdf」でした。
これよりさらに上のサービスをご希望の方は、「Smallpdf Pro」という有料サービスもあるようなので、こちらも検討してみてはいかがでしょう?
でも、数ファイルをちょこっと使う分には、無料版で十分ですね。

  • この記事いいね! (0)
村上 著者:村上

【サイト】マストドンのclient_idとclient_secretを取得できる「Access Token Generator for Mastodon API」

マストドンのAPIを使う機会があり、既に他の方が作成してくださってあったコードを改変中していたのですが、その時にclient_idclient_secret が必要だったので、その取得方法について。

といっても取得は簡単で、こちらのサイトを利用しました。

Access Token Generator for Mastodon API
https://takahashim.github.io/mastodon-access-token/

 

使い方は、まずサイト左のFrom欄に、マストドンのURL、クライアント名を入力します。

クライアント名は、承認画面で表示させるアプリケーション名を入力します。
サイト名とか、アプリ名でOKです。

あとは、「Scopes」から、読み込みのみなのか、読み込み書き込みも許可するのか、と言った、マストドンAPIで行いたいことの範囲を設定します。
私は書き込みと、念のため読み込みもできるように、「read write」を選択しました。

必要事項を入力したら、あとは「Publish Access Token」のボタンをクリックするだけ!
マストドンサービスのログイン画面に切り替わるので、自分のアカウントでログイン後、連携を許可するかを訊ねられるので、連携を承認します。
その後、ページ右の Result に、access_tokenclient_idclient_secretが表示されます。
あとは、この取得できた client_id と client_secret を使って、利用したいマストドンAPIを実行します。

 

こういうID取得って案外面倒くさかったり、または大体のサービスで最初に一度くらいしか使わないので、すぐ忘れてしまうんですよね。
きっと私もすぐ忘れるだろうという事で、まとめました。
是非、ご参考にしていただければと思います。

  • この記事いいね! (0)
村上 著者:村上

【便利サイト】PNGやJPG画像を綺麗に圧縮してくれる「TinyPNG」

画像を圧縮したい、けど画質が粗くなるのはNG!というときにおすすめしたいサイトが、今回紹介する「TinyPNG」です。
Webサイトを作成する際、画像のサイズを小さくすることが重要になってきますが、このサイトを使えば、画像を圧縮しつつ、画質をほぼそのまま維持することができます。
ちなみに、私には圧縮前と圧縮後の写真の違いが全く分かりません。

TinyPNGへのリンクはこちら。

TinyPNG – Compress PNG images while preserving transparency
https://tinypng.com/

 

使い方はとっても簡単で、画面上部中央にある、「Drag your .png or .jpg file here!」と書かれた枠の中に、圧縮したい画像をドラッグするだけ!
もしくは、枠の中をクリックして、画像を選んでもOKです。
あとは、自動的に画像が圧縮されます。

圧縮後は画面が下記のように変わるため、「Download」をクリックして、圧縮した画像をダウンロードします。

今回の画像は、1.0MB から 246.2KB に圧縮できました。
実に 76% のサイズダウンです。

で、実際に圧縮した画像がこちら。
上がオリジナルで、下が圧縮後の写真です。

▼オリジナル

▼圧縮後

目が良い人にはわかるかもしれませんが、70% も圧縮したとは思えない画質です!
これならば、問題なくWebサイトにも利用できますね。

Webサイトの高速化にお悩みの方は、是非こちらのサイトで画像の圧縮をお試しになってはいかがでしょうか。

  • この記事いいね! (0)
takahashi 著者:takahashi

NginxでBASIC認証をプロキシするときの注意点

今回。hamamatsu-gnss.orgのサーバー切り替えを行ったのですが、移行先サーバでサービスの再起動後何故かBASIC認証が通らなくなる問題が発生。
80番ポートはWebページとポートを共有しているので、webサーバーとntripサーバーの前にNginxを置いて、ドメインで通信を振り分けています。
旧サーバーでは問題なく動いていたのですが、まったく同じ設定をコピーした新サーバーでは、RTKLIBからntripへ401ステータスで接続できなくなってしまいました。

ちなみに直で新サーバー側のntripへ接続すると、認証も問題なく通り、ログにも異常は見られなかったので、原因がNginxなのは間違いなさそうです。

認証の要らないsourcetableはNginx経由でも問題なく表示できたため、恐らくBASIC認証の際に必要なヘッダ情報が渡せていないのだろうと推測しました。
そこでいろいろ調べてみると、参考になりそうなサイトを発見。

Nginx を認証プロキシとして使う – Docker-docs-ja

正常にプロキシするには

      proxy_pass                          http://example.com;
      proxy_set_header  Host              \$http_host;   
      proxy_set_header  X-Real-IP         \$remote_addr; 
      proxy_set_header  X-Forwarded-For   \$proxy_add_x_forwarded_for;
      proxy_set_header  X-Forwarded-Proto \$scheme;

の記述が必要だったのですが、新サーバーの設定ファイルと見比べたところ

proxy_set_header  X-Forwarded-Proto \$scheme;

の記述が抜けていることがわかりました。
この一行を追記し、Nginxをリロード、もう一度試してみると…

無事接続できました!

Nginxはプロキシする際、バックエンドへ渡すヘッダー情報を自由に指定・編集することができるので、抜けがあると今回のようなことが起きます。
Nginxでシステムを構築した際は、こういう部分も気を付けてチェックしたいですね。

いやーしかし、今回は症状がちょっと奇妙だったのでちょっとだけ焦りました…(笑

  • この記事いいね! (0)
takahashi 著者:takahashi

Twitterに新機能”スレッド”が追加! 連投が公式にサポート

高橋です。
先日、Twitterに新機能が実装されました。

Twitterに新機能「スレッド」が追加される 同じテーマの連続投稿が見やすく – HUFFPOST

Twitter上では以前から140文字を超える情報をどうしてもTL上で伝えないと行けないとき、1回目のツイートに返信する形で連投する、ということがよく行われていました。

今回のアップデートで、Twitterがこの”連投”をシステムとして実装。公式WebとAndroid/iOS版公式クライアントで利用できるようになりました。

いままで、返信でつなげて登録した際、うまく返信にならずにやり直したり、見る人によっては連投ツイートを見落とされたりする可能性がありましたが、今回のアップデートでより見てもらいやすくなりそうですね。

  • この記事いいね! (0)
takahashi 著者:takahashi

ハッカー力(りょく)を試すならここ! Hackmeでセキュリティを学ぶ

高橋です。

Webプログラミングをしていて必ず付いてまわってくるのがセキュリティ対策。
Webはプログラムが動作する環境そのものを外部に直接公開することになるので、脆弱性については特に気を付けないといけません。

しかし実際にどういうことに気を付ければいいのか…なかなか理解するのは難しいと思います。

そこで、一番手っ取り早い方法をお教えします。
自分自身が攻撃者としてサイトをアタックしてみればいいのです。

勿論、本当に誰かのサイトをハックするのは犯罪になってしまうので言うまでもなくダメです。
ただ、自分で(外部に影響のないような)練習用の仮環境を用意して、実際に攻撃者が行う手口を体験してみるのは大丈夫です。
むしろ、実際にどのように攻撃が行われているのかを知ることで、守る側に立った時も、どうすれば防御できるのか作戦を立てることができるようになります。習うより慣れろ、というわけですね。

ただ、自分でその練習用の環境を作るとなると、サーバーを用意して、サイトを用意して…となると結構大変です。

実は、そんなセキュリティを学びたい方のために、こんなサイトがあります。

Hackme“というサイトです。

このサイトでは、実際によく使われるハッキングの手口をつかってサイトの認証の突破にチャレンジすることができます。
ちょっとおバカなミスをついたものから、SQLインジェクションを用いた技術的なものなど、Webプログラムをしていて犯しがちな脆弱性を実際に突きながら、Webプログラムをする際にどういったことに気を付ければいいのか勉強することができる非常に面白いサイトです。

興味のある方は是非挑戦してみてはいかがでしょうか。

ちなみに、一口にハッカーとは言っても、必ずしも悪意のある人を指すわけではありません。
もともとハッカーという言葉は、”コンピューターに詳しい人”を指し、攻撃者だけを指す言葉ではありませんでした。

ハッカー – Wikipedia

そういった事情から、不正アクセスを行う人々を”ハッカー”と十把一絡げに読んてしまうと、あまりいい顔をしない人もいるようです。

この場合、悪意をもった攻撃を行う人のことを”クラッカー”と呼び、明確に区別することがあります。
最近では”ブラックハッカー”という呼び方もよく見かけます。

これに対し、”ホワイトハッカー”という人々もいます。
この人たちは、”ブラックハッカー”が行ってくる高度なクラッキング行為を防御する技術をもった人のことを呼びます。
所謂、セキュリティ技術者のことです。

コンピューターセキュリティの救世主 「ホワイトハッカー」の素顔に迫る – 日々タス

ホワイトハッカーを目指して勉強してみるのも面白いかもしれませんね。

  • この記事いいね! (0)
takahashi 著者:takahashi

nginxでSSL設定をするときに気を付けたいこと

高橋です。

以前家で趣味でnginxを使ってサーバーを建てたときの話。
Nginxを後ろに控えているWebサーバー(Apache)のリバースプロキシとして構築していました。

構成としてはサブドメインを割り当てたバーチャルホストが複数稼働している環境だったため、nginx側もバーチャルホストに対応すべく下のような設定にしていました。

 #省略...
 server {
  server_name  .example.com;

  listen          80;
  listen          443 ssl;

  ssl on;
  ssl_certificate      /ssl/to/path/example.com/fullchain.pem;
  ssl_certificate_key /ssl/to/path/example.com/privkey.pem;

  client_max_body_size 1g;
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # クライアントの IP アドレス
  proxy_set_header X-Forwarded-Host $host; # オリジナルのホスト名。クライアントが Host リクエストヘッダで渡す。
  proxy_set_header X-Forwarded-Server $host; # プロキシサーバのホスト名
  proxy_set_header X-Real-IP $remote_addr;
  location / {
    proxy_pass https://xxx.xxx.xxx.xxx;
  }

}
   server {
  server_name  .a.example.com;

  listen          80;
  listen          443 ssl;

  ssl on;
  ssl_certificate      /ssl/to/path/a.example.com/fullchain.pem;
  ssl_certificate_key /ssl/to/path/a.example.com/privkey.pem;

  client_max_body_size 1g;
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # クライアントの IP アドレス
  proxy_set_header X-Forwarded-Host $host; # オリジナルのホスト名。クライアントが Host リクエストヘッダで渡す。
  proxy_set_header X-Forwarded-Server $host; # プロキシサーバのホスト名
  proxy_set_header X-Real-IP $remote_addr;
  location / {
    proxy_pass https://xxx.xxx.xxx.xxx;
  }

}
#省略...<span data-mce-type="bookmark" style="display: inline-block; width: 0px; overflow: hidden; line-height: 0;" class="mce_SELRES_start"></span>

すると..

Bad Requestのエラーが発生。
いろいろ試してもエラーが解消されず頭を抱えていたのですが、調べていたら以下のサイトを発見。

nginx連載6回目: nginxの設定、その4 – TLS/SSLの設定 – インフラエンジニア way
https://heartbeats.jp/hbblog/2012/06/nginx06.html

>sslディレクティブをonに設定すると、SSLが有効になります。ただし、listenディレクティブでsslパラメータを指定したときには不要です。

>ssl on;

>listenディレクティブにsslパラメータを付けると、そのポートでSSLを有効にして待ち受けるようになります。そのポートに関して後述するsslディレクティブをonにしたのと同じ動作になるため、sslディレクティブの記述は不要になります。

>listen 443 ssl;

なるほど、
ssl on;
の記述をしてしまうと
server{}
内で定義されている全ポートにsslが有効になるので、80番ポートでアクセスしてもssl通信と解釈されてしまい、エラーが出ていたようです。
443ポートだけsslにしたい場合は

listen 443 ssl;

とだけ指定しておけば443ポートだけsslを有効にできるようです。
てっきり

“ssl on;”

を入れないとsslが有効にならないものと勘違いしていました(汗

さっきの設定を修正すると以下のようになりました。

 #省略...
 server {
  server_name  .example.com;

  listen          80;
  listen          443 ssl; #これは残しておく

  #ssl on; コメントアウト
  ssl_certificate      /ssl/to/path/example.com/fullchain.pem;
  ssl_certificate_key /ssl/to/path/example.com/privkey.pem;

  client_max_body_size 1g;
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # クライアントの IP アドレス
  proxy_set_header X-Forwarded-Host $host; # オリジナルのホスト名。クライアントが Host リクエストヘッダで渡す。
  proxy_set_header X-Forwarded-Server $host; # プロキシサーバのホスト名
  proxy_set_header X-Real-IP $remote_addr;
  location / {
    proxy_pass https://xxx.xxx.xxx.xxx;
  }

}
   server {
  server_name  .a.example.com;

  listen          80;
  listen          443 ssl; #これは残しておく

  #ssl on; #コメントアウト
  ssl_certificate      /ssl/to/path/a.example.com/fullchain.pem;
  ssl_certificate_key /ssl/to/path/a.example.com/privkey.pem;

  client_max_body_size 1g;
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # クライアントの IP アドレス
  proxy_set_header X-Forwarded-Host $host; # オリジナルのホスト名。クライアントが Host リクエストヘッダで渡す。
  proxy_set_header X-Forwarded-Server $host; # プロキシサーバのホスト名
  proxy_set_header X-Real-IP $remote_addr;
  location / {
    proxy_pass https://xxx.xxx.xxx.xxx;
  }

}
#省略...

これでnginxを再起動したところ、無事80番ポートの平文通信と443ポートのSSL通信両方ともできるようになりました。

Nginxは非常に細かい設定ができるのが人気の理由の一つですが、その分設定の仕方を理解しておかないとハマってしまうことも…

もっと勉強が必要だなぁ、と感じた瞬間でした…

  • この記事いいね! (0)
takahashi 著者:takahashi

【遂に動き出した5G通信】政府が5Gの新規参入を促進

高橋です。

Twitterモーメントで携帯回線の新通信規格 “5G” が取り上げられていました。


5G(5th Generation=第5世代移動通信システム)とは、4Gに続く現在規格化が進行中の次世代無線通信システムのこと。

第5世代移動通信システム – Wikipedia

4Gのアップグレード版になるので、当然4Gよりも性能が高くなるのですが、その上がり幅が凄い。
なんと理論値10Gbps以上の通信が行えるようになるとのこと。
現在の固定回線のFTTH(光ファイバー)も、大体理論値が1Gbpsぐらいなので、5Gが実稼働すればそれを大きく上回ることになります。
一方で、多接続可能かつ低遅延化と、IoT機器を意識した仕様も取り入れる予定だそうです。

そんな5Gですが、いままでMNO大手3社による寡占状態から脱却するために、政府が5Gに使われる電波帯域の割当制度を見直し、大手3社以外の新規参入を促進しようとしているとのこと。

次世代移動通信「5G」って何? 2020年の暮らしはどう変わる? – 価格.comマガジン

いままでも新しい通信業者を増やして価格競争を生むために、SIMロック解除義務化やMVNOの参入など、いろいろ措置は取られていましたが、携帯回線は飽くまでMNOの通信網をまた貸ししてもらう方法しかなく、根本的な解決になっていませんでした。

一方、今回は基地局が使う電波の割り当てを、現在のMNO以外にも行うかもしれないとのことで、これが実現すればもっと激しい価格競争が生まれて高い通信量が値下げされる可能性も出てきそうです。

5Gは2020年の実用化を目指しているということで、オリンピックが始まる頃には、大容量の通信網でいろいろなことができるようになっているかもしれませんね!

  • この記事いいね! (0)