Chrome68 オートフィルを抑止したいだけなのに新規パスワード生成メニューが出る

Chrome68で、

autocomplete="new-password"

が設定されたパスワード入力欄をクリックすると…。


↑
Chromeが生成したパスワードをおすすめします…というメッセージ。
これまでは、オートフィルを抑止するだけで、右クリックするとChromeで記憶しているパスワードを呼び出す事ができたのですが…。
新規パスワードなのに記憶したパスワードを使う？という判断をするようになったようです。

フォームの自動補完を無効にするには - ウェブセキュリティ | MDN

他人のパスワードを指定するようなユーザー管理ページを定義していて、パスワード欄のオートフィルを抑止したい場合は、 autocomplete="new-password" を使用することができます。ただし、この機能はまだ Firefox に実装されていません。

↑
この記事を参考にして、autocomplete="new-password"を使っていたのですが、元の記事も加筆されていて、他人のパスワードを指定するような時…となっていますね。

POTI-boardの編集・削除用のメンテナンス欄は数字+パスワードなのですが…。


↑
数字のところに、ユーザー名=名前がオートフィルで入ってしまって…。
ここは数字なのだから、明確にこの入力欄には数字しか入らないようにできないのかな…と思って検索してみたら…。HTML5には、input type="number" が…。

<input type="number" min="1" name="del[]" autocomplete="off" class="edit_number">

↑
無指定だとマイナスの数字も入ってしまうので、最小値を1に設定しました。


↑
数字の入力欄をクリックすると、ユーザー名として記憶されている名前がでてきますが、全角文字なので数字の入力欄には入らない。パスワードは記事の投稿時に記憶したものが入るので、編集・削除の時に困らない。
とりあえずは…これで何とか。

もしかしたら、もっといい方法があるのかもしれないのですが…。

POTI-board用テンプレート PINK を配布します。: STP^3
↑
配布しているテンプレートも修正してバージョンアップしておきました。

POTI-boardのエンコードをutf-8に固定

potiboard.phpの80行目付近のswitch文をコメントアウトして、utf-8にするところまでは、運営している絵板サイトでもやっていました…。

//switch(CHARSET_OUT){
// case 1 : $charset="EUC-JP";break;
// case 2 : $charset="Shift_JIS";break;
// case 3 : $charset="ISO-2022-JP";break;
// case 4 : $charset="UTF-8";break;
// default : $charset=CHARSET_OUT;
//}
define('CHARSET_HTML', "UTF-8");

でも、確かconfig.phpの

define('CHARSET_OUT', '4');
define('CHARSET_IN', '4');

を4以外に変更すると、問題が起きたような…。
思っていたよりも、面倒な作業だと思ったので、途中でやめていたのですが…。

GitHub - satopian/poti-kai: POTI-board, the oekaki BBS

[2018/08/22] v1.44.3 lot.180822【仕様変更】 文字コードをUTF-8に固定

utf-8固定になりました。


↑
define('CHARSET_OUT', '2');
2:Shift_JISにすると文字化け…。
この設定はまだ生きているようです。


↑
define('CHARSET_IN', '2');
2:Shift_JISにすると投稿できなくなりました。
この設定もまだ生きているようです。


↑
$charsetが未定義になっているような気がしたので、echo $charset;
すると、CHARSET_IN、CHARSET_OUTそれぞれの値がレス返信モードの時に表示されました。
$charsetが4にならないと、期待した動作にならないようです。

対処。


↑
define('CHARSET_CONVERT', '0');
という事は、 if(CHARSET_CONVERT) return $str; のif文は必要ないのでコメントアウト。続くswitch文も無効にして、utf-8に固定。

potiboard.php内の、CHARSET_OUTと、CHARSET_INを4に置換。

config.phpで設定を変更しても無効になる事を確認するため、
設定項目そのものをコメントアウト。

数時間テストしてみましたが…これで問題ないようです。
お絵かき掲示板交流サイトで使っているPOTI-boardに導入しました。

文字エンコードの設定項目がなくても、utf-8で正常動作するようになった…と本人は思っていますが…。
本人以外のほうが気が付きやすいのがバグですから、おかしな動作をしているようでしたら教えてください。

この仕様は、POTI-board改 v1.44.4 lot.180825に反映されました。

お絵かき掲示板はこちら。

お絵かき掲示板交流サイトのSSL/TLS対応作業を行いました

↑
google Chrome。
左、保護されていません、右、保護された通信。


↑
Firefox。
左、この接続は安全ではありません、右、警告表示なし。

https;// なのに、 http:// の画像がまぎれこんでいると混在表示コンテンツになり、すりかえられた画像の可能性があるという警告がでますが、秀丸エディタのgrepして置換で処理。

アクセスログのための1pxの画像を、　http:// から、// に書き換えて、https:// でも、http:// でも対応できるようにしました。
何ページ分あっても、同じタグの書き換えなので、grepして置換すれば数秒で終わります。

さくらのブログはSSLに対応していませんが画像はhttps://でも呼び出す事ができるので、RSSからブログの画像を取得するphpを書き換えました。

<?php
//SSL対応 http:を取り除く
$image = $item->thumbnail;
$image = ltrim($image, "http:");
?>

PHP: ltrim - Manual

ltrim − 文字列の最初から空白 (もしくはその他の文字) を取り除く

ltrimで、画像のURLからhttp:を取り除きました。

何もかもスムーズにいく…と思ったのですが…。

TLS 1.0/1.1無効化のメンテナンスによる影響 – さくらのサポート情報

通信の安全性を確保するため、 「弊社レンタルサーバで運営されているお客様のウェブページ」
における「TLS1.0/1.1」による暗号化通信を無効化いたします。

.htaccessでリダイレクトをかけたところ、Mac OS10.6、Windows XPで投稿している方がアクセス不能に…。
リダイレクトをかけるのをやめました。

https://から、sを取ってもらい、http:// で掲示板を使ってもらう事に…。
でも、Windows7以降ならTLS1.2に対応したブラウザを使う事ができるから何も意識しなくても大丈夫…と思ったら、コメントの投稿時に「〜を待機しています」が長く続き「このページは動作していません」が頻発。

20回に一回の割合で画面がかたまってしまいました。

〜を待機していますが長時間続きエラーになる時は | 気軽にお絵かき | お絵かき掲示板交流サイト

セキュリティ対策ソフトの影響によりgoogle Chromeなどで、「pbbs.sakura.ne.jpを待機しています」という表示が長く続き、「このページは動作していません」というエラーになる事があります。
一部のSSLサイト（「https://」で始まるWebページ）が表示できない | ESETサポート情報

軽いから使っていたNOD32アンチウイルスが原因でした…。
「SSL/TLSプロトコルフィルタリング」機能からChromeを除外したところ、Pawooで頻発していたトゥートボタンを押した時に固まる事がある問題も解決しました。

他にもESETのセキュリティ対策ソフトを使っている方がいる筈ですから、設定の変更をお願いしなければならなくなってしまいました…。

そして、SSLにしたら、検索順位が下がって表示できなくなってしまったコンテンツ…。
いつかは元に戻るのでは？と思いながら何度も検索。

思っていたより労力が必要でした…。

お絵かき掲示板はこちら。

BBSNoteから&#x3C;center&#x3E;を除去する

BBSNote8.0b19は、Perl5.12以上では動作しません。
つまり、今改造してもほとんどのサーバで動作しません。
さくらのレンタルサーバではPerl5.10が使えるので、とりあえずなんとかなっていますが…。
BBSNote後継のComet1.0をダウンロードしておくべきでした。
CometはPerlのバージョンがあがっても動作しているようです…。

そんなBBSNoteのメンテナンスを行いました。
<center>と、<div align="center">を取り除く作業…。
tableを完全に撤去するのは困難だったので、tableにCSSを適用してみたり<div class="hoge"> </div>で囲んでみたり…。

↑
tableにtext-align: centerを適用した箇所もありますが、あくまでもテキストの中央寄せのためで、tableそのものは、margin: 0 auto。左右のmarginを自動でというセンタリング。
divをセンタリングする時と同じ。


↑
text-align: centerを適用したくない箇所のテキストまでセンタリングされてしまったので、そのtableの中のさらにtableはtext-align: leftになるように…。
<center>なら簡単に指定でるきのに、CSSの行数が増えて行く。
そして、とうとうbbsnote.cgi本体の改造…。


↑
ここを変更したらどこが変わるのかわからないからそれっぽいところを一箇所ずつ変更してソースを確認…という総当たり方式で問題の箇所を見つけ出し、tableにclass名をつけました。
場合によっては、tdだったりtrだったり…。


↑
そこまでやっても、W3Cチェックで出るエラー1245…。
今のWebの基準を作っているのはW3Cなのか、googleなのか…。
google Chrome、IE、Firefoxで意図通りの表示、使う上でなにか問題がある訳ではないのですが…。

お絵かき掲示板はこちら。