スレ立てるまでもない質問はここで 154匹目
■ このスレッドは過去ログ倉庫に格納されています
>>383
ブランチ管理してくれるならバックアップでもいいかな
あとリストアも自動で
BunBackupでそこまでの機能ってあったっけ? >>384
IEEE754の規定では、9.0/3.0なら正確に3.0を返さなければならないはず。 名前空間で分類してるからクラス名を積極的に短くする
vs
かぶらないに越したことはないのでクラス名は長く書く
どちらが正解なのでしょうか?
//shared code
namespace Domain {
Foo
FooDetail
Bar
IFooRepository
IBarRepository
IFooService
IBarService
} //長い名前派
TooLongName.cshtml
namespace UI {
TooLongNameViewModel
TooLongNameFooViewModel
TooLongNameFooDetailViewModel
TooLongNameBarViewModel
TooLongNameModelMapper
TooLongNameController
TooLongNameFacade
TooLongNameOther
}
//短い名前派
TooLongName.cshtml
namespace UI {
TooLongNameController // 設定より規約パターンのために短くできない
namespace TooLongNameDetail {
namespace ViewModels {
Foo
FooDetail
Bar
}
ModelMapper
Facade
Other
}} この手のものに正解は無いので
名前空間の方が好みだし、名前は短い方がいい 名前空間使って短くするほうが圧倒的に良いと思うけど切り方が微妙 >>395
参考までにあなたならどのように切りますか? >>397
多分、条件式の方が正しいと思うが、
250個以上のプログラム言語があるから、
条件文も正しいかも知れない。 まあ確かに言語によるかもしれんけど
条件文とは例えばif文とかの全体を言っていて
if(ここ) に入れるのが条件式と言ってるとかじゃないかね? >>400
よく使われている常識的な言語だとそうだろうね。
独特の用語の使い方をする言語もあるから責任は持てないけれど。 >>396
オーソドックスにやるならView/ViewModel/Controllerは
Presentation Layerの中に並列に切る
WebUI.Views
WebUI.ViewModels
WebUI.Controllers
アーキテクチャ次第だから絶対にこうすべきという物があるわけではないけど
とりあえずメジャーなサンプルプロジェクトを参考にしてみては?
https://github.com/dotnet-architecture/eShopOnWeb
https://github.com/jasontaylordev/NorthwindTraders >>392
Ruby on Rails では、1単語が多い
bookmark, comment, todo とか、皆が使う 認証ありのSPAをSpringBoot2とReactで実現したくて勉強をしています
いろんなサンプルプロジェクトを落としてきて見ているのですがどれも認証トークンをローカルストレージに保存する手法で作ってます
こちらの記事ではそういう大事な情報をローカルストレージに入れるのはマズいと書かれていました
https://techracho.bpsinc.jp/hachi8833/2019_10_09/80851
個人的には記事の内容の通りだと思うのですが多数のプロジェクトで使用されているからには何か対策があるからなのでしょうか
またローカルストレージを使用しない手法を使用したプロジェクトをご存知であれば教えていただきたいです >>404
その記事でcookie使えと書いてあるじゃないか MVCフレームワークならいつもと同じようにCookie認証すればOK
すると通常リクエストにもAJAXリクエストにも自動的に認証Cookieが乗っかる
後はCSRF対策用のヘッダーだけ載せ忘れないようにAJAXリクエストを共通コードでラップしておけば完璧 ありがとうございます
Cookie認証で実装しているプロジェクトを探してみます これでも結局はクッキーで送られたIDでAPIをアクセスするんやろ?
一緒やんと思うんやけど何故これでセキュアと言い切れるのか XSS対策 http only Cookie
盗聴対策 secure Cookie
CSRF対策 アンチフォージェリトークン
弱点は、ないッ! >>408
雑に説明するなら、http only cookie はスクリプトからアクセスできないから
とりあえずCSRF周りの記事を読み漁るといい >>409
強引に難しいルートとしてだけど攻略不可能でもないと思う
DNSポイズニングで偽証明局掴まされて、中間者攻撃でTLSを中継されたらどうしようもない XSSされたらCookie取られなくても即死じゃね?
正規のエンドポイントに不正リクエスト送られてアウト >>410
そんなのコードだけの話でパケットみたら丸わかりやん・・・
こういうのでセキュアってなんか違うんじゃね?
CSRFってこれもトークンなんだし結局は一緒かと 自分で作ったWebAPI(Lambda)からデータをGETするだけのサイトを作りたいのですが、フロントも自分で作った方がセキュリティ的に安全なのでしょうか?
もしセキュリティ的に問題無いのでしたらlivedoorブログとかで代用したいです >>415
問題ない
GETは普通のHTTP GETだから パスワード再設定のためにワンタイムパスワードをメールで送るパターンを採用してるシステムがよくあるけど
このメールって盗聴されたりしないんですか? >>418
これってクライアントから直近のSMTPサーバーまでの暗号化を強いるだけじゃないんですか?
SMTPリレー中のサーバーが1つでも非対応の場合は盗聴されてしまうのでは >>419
そうだけど、それはそのサイトの問題じゃないよね
変なメールプロバイダ使ってる人の問題
それに実際の話、サイトのOTPだとバレたとしても何か問題ある?
アカウントと紐付いて初めて問題になるから >>420
あ、いや問題はあるか
問題のあるプロバイダ使ってる人のアカウントを特定できるなら、パスワード再設定して盗聴したOTPでログインとか >>419
まあ、大体がメールのリレーに割り込むこと自体のハードルがかなり高いし やっぱりメールだとセキュアではないですよね…
なんでこんな脆弱なプロトコルがスタンダードのまま野放しになってるんだろう メール送信先と、OTPの発行されたシステムのアカウントの紐付けはどうやるんだろう
メールにアカウントのIDが書いてあったり下手なURLが書いてあったとしたら設計側の問題だよな セキュリティを気にするのだったらメールで認証するなということだな
昔の技術にただ乗りしているのだからメールシステムに問題があるんじゃなくて
採用する側が問題 セキュリティに「これしとけば完璧」なんてないのよ、いたちごっこだから
した方がしないよりはマシ
複数からの同時ログインを特別扱いしとけば横取りされたらすぐわかる、わからないよりはマシ
OTPは時限だし 1. ランダムトークン、メールアドレス、パスワード、タイムスタンプ、IP、セッションIDなど仮登録
2. 検証URLのクエリパラメータにランダムトークンのみを付けてメール送信
3. 検証URLにアクセスが来たらランダムトークン、有効期限、IP、セッションIDなど検証してメールアドレス、パスワードを本登録
メールはどう頑張っても盗聴される可能性がある
検証を厳しくすると、登録はPCだけどメール確認はスマホ、のパターンに対応できなくなる
検証を厳しくしても、メール盗聴者によるなりすましは防げない
検証を厳しくすると、うっかりクリック狙いのなりすましを防げる
初期登録の場合、メール盗聴されても個人情報、機密情報が抜かれることはないが、勝手に本登録されてしまうことはある
パスワード強制リセットの場合、ランダムパスワードをメール通知するか、メール認証の後で再入力を促すしか方法がないので、メール盗聴されるとアウト
リセット後、可能な限り速やかに、WEB画面からパスワード変更すべし
こんなところですかね
セキュリティ難しすぎて辛い 復号化するキーを画面上で発行してメールの中身を暗号化したり
ワンタイムパスワードをセッションID使って暗号化しておいて
同じセッションじゃないと使えないようにしたりすれば
メールアドレス == アカウントでもだいぶセキュアになるかも
でもパスワード忘れるような人にとってそういうのは異常にハードル高くて
サポートコストが増大するから特別なサイト以外はやらない
利便性とセキュリティのほどほどのバランス >>428
盗聴者がセッション開始することもできるからそれでは防げないかと
盗聴者:盗聴対象メールアドレスを入力、パスワード再設定セッション開始
盗聴者:パスワード再設定メールを盗聴、ワンタイムパスワード取得
盗聴者:ワンタイムパスワードを入力、パスワード再設定
盗聴者:パスワード再設定セッション終了
〜〜〜〜
正規ユーザー:身に覚えのないパスワード再設定メールを受信(この時点で手遅れ)
メールだとパスワード再設定が脆弱すぎる
パスワード再設定はメールじゃなく電話、SMSを必須にしたほうがいいのかも 不正アクセスに関しましては全て被害届を提出します
過去に実績もあります
って書いてればビビリからは攻撃受けないだろ
まぁ自動化して攻撃してるだろうから意味は無いかもしれんが >>429
標的のメールが常に盗聴可能な状態でパスワード再設定に必要な情報も持ってるって前提ならね
セキュリティに100%はないから
どういう種類の攻撃に対してどの程度の防御ができてるのかと
その攻撃が実現しうるリスクの程度で評価しないと なるほどメールアドレスがそのままアカウントIDになってるサービスでは盗聴に弱いのか
ならパスワード強制リセットのページにも別のワンタイムトークンを表示しておけば……いやそんなことしなくてもWeb側のセッションIDとメールの認証キーを内部で照合すれば、セッション固定攻撃と組み合わせない限りは安全なのでは? メール受信による認証は盗聴に弱いから、多要素認証の一部として効果を発揮するのであって、単独でパスワードリセットができるのは安全性が低い
せめて生年月日とか電話番号とかを合わせて聞くようなリセット方式にしないと心許ないってところかな セキュリティに100%はない
しかしマスコミをそれを知ってか知らずか
破られると猛烈にたたく
システムを作る側としては解がないわ 参考にAmazonのパスワードリセットのワークフローを調べた
1. メールアドレス入力、サブミット
2. ワンタイムパスワードメール受信
3. ワンタイムパスワード入力、サブミット
4. 新パスワード入力、サブミット
盗聴者が攻撃しようとしたらこれで攻撃できちゃうのでは?
1. 攻撃対象メールアドレス入力、サブミット
2. ワンタイムパスワードメール盗聴
3. ワンタイムパスワード入力、サブミット
4. 新パスワード入力、サブミット
Amazonが採用してるぐらいだからメール盗聴のリスクは考えなくてもいいのかな?
もう、わかんねえなこれ >>435
あー、なるほど、そのための秘密の3つの質問か
アレ、なんのためにあるのか謎だったけど必要な物だったんだな >>398-401
レスありがとうございます
そもそもプログラムの世界でいう「式」って、何なんですか?
「文」は理解できたけれど、「式」がいまいちピント来ません。
(どうしても算数の「式」のイメージが強くて抜けない)
文を構成する要素を「式」だと考えればよいですか? 式は評価できるもの
評価すると値やオブジェクトを得る
式は式や文の構成要素となる 式は式、項、因子から構成される
式は因子の構成要素にもなる Javaのifはif文なので直接変数に代入できない
Kotlinのifはif式なので直接変数に代入できる プログラムなんてレベルじゃないので申し訳ない質問ですが、スプレッドシートで同じシート内の別タブにリンク飛ばしたい場合、PCでは飛べるけどiPhoneのアプリからは、「リンクを取得」を押しても飛べないんですけど、仕様ですか?やり方あったら教えてほしいです。 Ruby では、if は文ではなく式なので、戻り値を返す。
Rubyの影響を受けている、Kotlin, Rust, Go など、最近の言語は式重視
p res = if 1 + 2 == 4
"yes"
else
"no"
end
res は、no となる SQLで四則演算させたりするのはあまり良くないのでしょうか?
そういう処理はアプリ側だけにしてSQLは極力シンプルにするのが理想ですか? そんな質問をする程度のレベルなら極力SQLに寄せた方がいい
プログラミング言語は自由度がとても高いので、酷いコードは本当にどうしようもない底無しのビチグソであり、深刻な技術的負債となる
それに比べればSQLは巧拙次第でパフォーマンスの差はあれど、バカでもそこまでソフトウェアの品質に壊滅的影響を与えることは少ない わかりました。ではこれからSQLを電卓アプリ代わりに使っていきます。 >>445
それは C の条件演算子/三項演算子(どちらもダサいネーミングだと思います)とか lisp の cond 特殊構文などの形で過去にありましたね Fortranでopenmpやり始めたんですが、遅いので調べてみたら、openmpを呼ばないで(シリアルと同じコード)単にOMP_NUM_THREADS =2とするだけで、OMP_NUM_THREADS =1より遅くなってしまうんですが、どういうことなんでしょうか。 SQLで頑張らなきゃいけないのは結局テーブル設計がダメってこと >>453
テーブル設計がいいと、SQLで頑張らなくていい例を
1つでいいからあげてください
ないならそのまま逃げて構いません(笑) >>454
クソテーブル設計者さん朝から発狂しちゃった……w >>453
SQLで頑張らなきゃいけない場合と
SQLで頑張ることを選択した場合を区別してるなら
おおむね同意 テーブル設計がシステム要求に対して適切じゃなかったからSQLが複雑になったなんてのはあるけれど
逆は必ずしも真じゃないわな。 >>445
Haskellの事も忘れないで・・・。
if式も有るけど、パターンマッチでifそのものも作れますよ。
myif True t f = t
myif False t f = f
先行評価だと、引数を全部評価しちゃうから、正常に動作しない。
遅延評価だからこそif式を自作出来る。 テーブル設計よりアプリケーション設計のほうがSQLへの影響が大きい
リポジトリパターンを採用すればテーブル設計が糞だとしてもそれほど複雑なSQLにはならない
スマートUIを採用するとテーブル設計が綺麗でもほぼ確実にSQLが混沌に導かれる >>459
モデル設計の話をDBとごっちゃにしている点で、そのパターン論争は糞だと思うけど ひどい脱線で言い争ってるなあ
最初の質問は
>SQLで四則演算させたりするのはあまり良くないのでしょうか?
だぞ
質問者そっちのけで言い争って勝って自分の有能さを誇示したいのか? >>460
SQLはDBモデルからAPモデルへの関数(射影)でしかない
なのでSQLを考えるときにAPモデルのことを考えないということはありえない
そして関数(射影)というものはどちらかというとINよりもOUTの構造が綺麗なほうが綺麗に実装しやすい
複雑なデータを綺麗に整頓するよりもデータを意図的に複雑化するほうが難しいからだ
であるからAPモデルが糞(スマートUI)ならDBモデルが糞であろうとなかろうとSQLも糞と化す
APモデルが綺麗(DDD, リポジトリパターン)ならDBが多少糞でもSQLはそれほど糞にはならない >>462
糞はフンと読みますかクソと読みますか? >>446
開発者やチームのスキルが常軌を逸したびちぐそレベルではないと仮定して
四則演算やそれに類するロジックなんてSQLでやらないほうがいいと思う
SQLの中のロジックに対してユニットテストが書けない
バグがあるときデバッガで途中経過を追えない
SQLにロジックを入れるとしたら、インデックスが活きる操作等、性能的な意図があるもの >>462
だからモデル設計のみで考えるべき問題
SQLなんて低レベルのレイヤーの都合を持ち込んで考えるからおかしくなる
だから、その論争は糞 SQLに色んな処理を書く人は
PHPとHTMLをごちゃ混ぜにしてるぐらいセンスないね 計算は別のところでやって
DBにはその答えを全部記憶していけばいい
究極のメモ化が完了する まとめ
* 原則的にはSQLにドメインロジックを書かない
* パフォーマンスなど理由があるならば原則を破ってよい
* 原則を破る場合は積極的にドキュメンテーションすべし
次の方どうぞ >>468
計算した結果が出るViewを作ったりしてな。
マテリアルビューとかでやれば普通の表と似たようなものか。 小学生です。
今九九を自動化するためにDBに1の段のテーブル、2の段のテーブル……と作っています。
例えば8×7の場合は
select result from 8_no_dan where kakeru_aite = 7;でresultに56が出てきます。
これって商品化できますか? >>464
> 四則演算やそれに類するロジックなんてSQLでやらないほうがいいと思う
> SQLの中のロジックに対してユニットテストが書けない
データベースを入れないでテストしても正しく動作するという保証はできません
データベースを入れてテストするならテストはできます >>464
書きやすさやりやすさの違いはあるだろうけど
SQL内のロジックに対してもテスト書けるしデバッガも使えるでしょ >>469
>* 原則的にはSQLにドメインロジックを書かない
四則演算はすべてドメインロジック? 同じ糞ならSQLのほうがマシ、は真
適切なフレームワークさえあれば、本質的にはコードよりよほどテストは容易 >>475
それはユニットテストの範囲じゃなくてインテグレーションテストの範囲でしょ >>476
SQL内ロジックのデバッグは知らないのでよかったら教えてほしい
ストアドファンクションのデバッグなら知ってる >>479
SQLは単体テストでしょ
世の中、ORMや典型的なリポジトリパターンだけで作れるような簡単なシステムばかりじゃないよ 単体か結合かはあまり気にしなくていい
要点は自動化できるかどうか
SQLは自動テストできるがとにかく遅い
規模が大きくなるとその遅さに耐えられなくなる
なのでSQLはテストしなくてもいいぐらい単純化する
複雑なビジネスロジックでもインフラが関わらなければ自動テストがすぐに終わる デバッグはしなくていい
関数のI/Oだけを見ればいい >>479
そうやってテストしないからバグが出る
ユニットテストの中でデータベースを使ってるだけに過ぎない
ユニットテストの中でファイルを使っていれば、ファイルの読み書き部分は省くのかよw >>483
てきとーにI/Oだけみて正しいと判断できちゃうような単純な関数しか実装させてもらえない人なのかな? >>485
単純に越したことはないがI/Oだけで判断できる純粋な関数はどんなに複雑化しても簡単にテストできる
なので経験を積んだ人ほど関数を好む
そして純粋な関数とはインフラストラクチャの定形的なコードと切り離された純然たるビジネスロジックそのもの
なのでそこを任されるということは実力を信用されているということだよ 互いの言葉尻だけ捉えて持論を垂れ流すレスバトルだな
自尊心を満たした気分になる以外に何のメリットがあるのか >>462
APモデルってなんですか?
アシスタント・プロデューサーって可愛いですか? >>487
有益な知識が少しでも広まれば国内の生産性が上がる
たとえそれが雀の涙のようなものだとしても無価値ではない ■ このスレッドは過去ログ倉庫に格納されています