ASP.NETのBlazorのスレッド part2です。
ASP.NET
https://dotnet.microsoft.com/apps/aspnet
ASP.NETは、クロスプラットフォーム対応、無料、オープンソースのフレームワーク
Free. Cross-platform. Open source.
A framework for building web apps and services with .NET and C#.
Introduction to ASP.NET Core Blazor
https://docs.microsoft.com/en-us/aspnet/core/blazor/?view=aspnetcore-5.0
【本命】Blazor スレ1【真打】
http://mevius.5ch.net/test/read.cgi/tech/1595255796/
Microsoft ASP.NET Blazor #02
■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
2020/11/22(日) 05:30:30.13ID:kDrPKY9d318デフォルトの名無しさん
2020/12/25(金) 10:04:08.77ID:JfQSa+1c >>317
その多種多様なデバイスの上で.NETが動くわけで
その多種多様なデバイスの上で.NETが動くわけで
319デフォルトの名無しさん
2020/12/25(金) 10:09:58.28ID:8j4BK9K7 ぜんぶ設計者次第だという認識
320デフォルトの名無しさん
2020/12/25(金) 10:16:11.17ID:81Ut/TdK >>314
WebなんてぶっちゃけDBと画面の間のマッピングを定義してるだけの話なので、
データモデルがRDBによって常に静的に型付けされているため動的型でも破綻しにくい
むしろ変にドメイン駆動とか意識高いのに毒されて画面から独立したモノリシックなビジネスロジック層みたいなのができちゃうと、動的型では確実に破綻する
WebなんてぶっちゃけDBと画面の間のマッピングを定義してるだけの話なので、
データモデルがRDBによって常に静的に型付けされているため動的型でも破綻しにくい
むしろ変にドメイン駆動とか意識高いのに毒されて画面から独立したモノリシックなビジネスロジック層みたいなのができちゃうと、動的型では確実に破綻する
321デフォルトの名無しさん
2020/12/25(金) 10:17:04.89ID:JfQSa+1c >>316
サーバー側の型がなにを指しているのかによるな
データアクセスレイヤのクラスがプレゼンテーションに漏れるのはBADだと思う
しかしドメインレイヤのクラスをプレゼンテーションから参照するのは問題ないと考えている
昨日も例を出したけど
入力として単価、消費税率、個数があってリアルタイムに税込み価格を表示する画面があったとする
この税込み価格の計算は明らかにドメインロジックだ
プレゼンテーションレイヤから直接ドメインレイヤを参照できればそれが最もシンプルでよろしい
もしそれができない場合、プレゼンテーションレイヤにも税込み価格計算ロジックを実装するかリモート呼び出しのためのエンドポイントを実装し、APIクライアントも実装するという重い作業を強いられる
もちろん、税込み価格計算はただの一例であり、実際にはより多くのニーズがある
プレゼンテーションレイヤからドメインレイヤの型を参照できると低コストでより高度な画面を作成することができる
サーバー側の型がなにを指しているのかによるな
データアクセスレイヤのクラスがプレゼンテーションに漏れるのはBADだと思う
しかしドメインレイヤのクラスをプレゼンテーションから参照するのは問題ないと考えている
昨日も例を出したけど
入力として単価、消費税率、個数があってリアルタイムに税込み価格を表示する画面があったとする
この税込み価格の計算は明らかにドメインロジックだ
プレゼンテーションレイヤから直接ドメインレイヤを参照できればそれが最もシンプルでよろしい
もしそれができない場合、プレゼンテーションレイヤにも税込み価格計算ロジックを実装するかリモート呼び出しのためのエンドポイントを実装し、APIクライアントも実装するという重い作業を強いられる
もちろん、税込み価格計算はただの一例であり、実際にはより多くのニーズがある
プレゼンテーションレイヤからドメインレイヤの型を参照できると低コストでより高度な画面を作成することができる
322デフォルトの名無しさん
2020/12/25(金) 10:22:24.07ID:JfQSa+1c >>320
それはどうかな?
意識の高いプログラマの代表格であるマーチンファウラー先生はrubyを称賛していたね
ドメインを実装するのに必ずしも静的でなければならなということはなさそうだ
重要なのはテストを書くことなのだろう
それはどうかな?
意識の高いプログラマの代表格であるマーチンファウラー先生はrubyを称賛していたね
ドメインを実装するのに必ずしも静的でなければならなということはなさそうだ
重要なのはテストを書くことなのだろう
323デフォルトの名無しさん
2020/12/25(金) 10:27:26.49ID:JfQSa+1c そもそもWEBをひとくくりに画面とDBのマッピングであると決めつけるのもいかがなものか
チュートリアルみたいな簡単な仕事ならそれでもいいのかもしれないが
現実のビジネスは小さな事業でもそんなに簡単にはいかない
チュートリアルみたいな簡単な仕事ならそれでもいいのかもしれないが
現実のビジネスは小さな事業でもそんなに簡単にはいかない
324デフォルトの名無しさん
2020/12/25(金) 10:32:50.39ID:vv0pxJyE325デフォルトの名無しさん
2020/12/25(金) 10:35:51.93ID:uurLZNKt >>322
C#であればコンパイラが型チェックしてくれるようなことすらも
Rubyは自力でテストを書かなければならない?
しんどくない?しんどくてもその分の見返りがRubyにはある?
いや数画面のスキャフォールドで作られたようなCRUDシステムなら好きな方選んだらいいと思うんだけど
中規模以上になってくるとどうなのかなと思って。
C#であればコンパイラが型チェックしてくれるようなことすらも
Rubyは自力でテストを書かなければならない?
しんどくない?しんどくてもその分の見返りがRubyにはある?
いや数画面のスキャフォールドで作られたようなCRUDシステムなら好きな方選んだらいいと思うんだけど
中規模以上になってくるとどうなのかなと思って。
326デフォルトの名無しさん
2020/12/25(金) 10:38:07.26ID:uurLZNKt327デフォルトの名無しさん
2020/12/25(金) 10:38:47.43ID:UA1/tVeu328デフォルトの名無しさん
2020/12/25(金) 11:01:46.48ID:bbGDaeBs 静的型チェックを重視するならC#よりF#使えばいいのに
329デフォルトの名無しさん
2020/12/25(金) 11:08:03.54ID:8j4BK9K7 訳わかんない理論がまかり通るスレ
330デフォルトの名無しさん
2020/12/25(金) 11:37:26.72ID:JfQSa+1c331デフォルトの名無しさん
2020/12/25(金) 11:45:17.08ID:JfQSa+1c >>325
動的言語はしんどいよ
自分個人としては動的言語には懐疑的
ただ高度なスキルを持った著名人が支持しているのでコード解析の弱体化のデメリット以上に何かしらメリットがあるのだろう
そしてそういった著名人は必ずテストも推奨している
テストを書かない場合は静的言語のほうが有利なのだろう
しかしテスト書けば動的言語の弱点が補われるのでメリットのウェイトが大きくなる
動的言語はしんどいよ
自分個人としては動的言語には懐疑的
ただ高度なスキルを持った著名人が支持しているのでコード解析の弱体化のデメリット以上に何かしらメリットがあるのだろう
そしてそういった著名人は必ずテストも推奨している
テストを書かない場合は静的言語のほうが有利なのだろう
しかしテスト書けば動的言語の弱点が補われるのでメリットのウェイトが大きくなる
332デフォルトの名無しさん
2020/12/25(金) 11:49:27.10ID:JfQSa+1c >>327
何もできないというのは間違い
しっかりしたシステムでは必ずクライアント側でもデータ検証を行っている
ただしそれはコード重複や無駄なリモート呼び出しの実装という負債を抱え込むデメリットと常にセット
フロントエンドとバックエンドで言語を揃えれば負債なしにフロントエンドでデータ検証を行うことができる
もちろんデータ検証以外の処理もおなじこと
何もできないというのは間違い
しっかりしたシステムでは必ずクライアント側でもデータ検証を行っている
ただしそれはコード重複や無駄なリモート呼び出しの実装という負債を抱え込むデメリットと常にセット
フロントエンドとバックエンドで言語を揃えれば負債なしにフロントエンドでデータ検証を行うことができる
もちろんデータ検証以外の処理もおなじこと
333デフォルトの名無しさん
2020/12/25(金) 12:16:12.84ID:uurLZNKt334デフォルトの名無しさん
2020/12/25(金) 12:24:33.08ID:cyV6b5qO それをここで聞いてもな…
親の仇の如く口汚く罵られるだけで、
メリットなんか提示されないと思うぞ
親の仇の如く口汚く罵られるだけで、
メリットなんか提示されないと思うぞ
335デフォルトの名無しさん
2020/12/25(金) 12:30:41.85ID:uurLZNKt だよね…
技術の優劣をつける意図はないんだが、
自分が作るシステムでは正しい技術を選択したいという想い
技術の優劣をつける意図はないんだが、
自分が作るシステムでは正しい技術を選択したいという想い
336デフォルトの名無しさん
2020/12/25(金) 12:31:52.62ID:fU2xV1RD >>321
明日もお願いします。
明日もお願いします。
337デフォルトの名無しさん
2020/12/25(金) 12:32:11.57ID:uurLZNKt Webフレームワーク比較検討スレみたいなのがほしい
js系の言語のスレはBlazorの話するとうざがられるし
js系の言語のスレはBlazorの話するとうざがられるし
338デフォルトの名無しさん
2020/12/25(金) 12:37:05.82ID:JfQSa+1c339デフォルトの名無しさん
2020/12/25(金) 13:33:23.39ID:pgbI6Wzr >>337
人気のweb frameworkのスレッドは個別にあるしそこでいい。
全部の言語まとめて扱うと荒れる。
JSやJavaのスレッドはある
Java Web Application Framework総合 ver2
http://mevius.5ch.net/test/read.cgi/tech/1374399677/
C#は乱立してないから素直にASP.NET使えばいい
5chみたいな狭い世界で比較検討せずに
素直に人気のあるやつをいくつか試して決めた方がいい。
人気のweb frameworkのスレッドは個別にあるしそこでいい。
全部の言語まとめて扱うと荒れる。
JSやJavaのスレッドはある
Java Web Application Framework総合 ver2
http://mevius.5ch.net/test/read.cgi/tech/1374399677/
C#は乱立してないから素直にASP.NET使えばいい
5chみたいな狭い世界で比較検討せずに
素直に人気のあるやつをいくつか試して決めた方がいい。
340デフォルトの名無しさん
2020/12/25(金) 13:37:24.42ID:pgbI6Wzr341デフォルトの名無しさん
2020/12/25(金) 13:55:33.58ID:8j4BK9K7 自演ぽいな
342デフォルトの名無しさん
2020/12/25(金) 14:03:41.81ID:l1B2LBGM そろそろ学習本が欲しいところ
アレ以外で
アレ以外で
343デフォルトの名無しさん
2020/12/25(金) 14:22:22.25ID:vv0pxJyE >>330
じゃ、Blazor Serverはリモート実行だから”メソッド共有”じゃないってことね
異なるプログラムで共通のライブラリを使うことを
”メソッド共有”って呼んでもなかなか通じないと思うよ
じゃ、Blazor Serverはリモート実行だから”メソッド共有”じゃないってことね
異なるプログラムで共通のライブラリを使うことを
”メソッド共有”って呼んでもなかなか通じないと思うよ
344デフォルトの名無しさん
2020/12/25(金) 14:24:09.99ID:JfQSa+1c >>343
ではなんと言ったらわかりやすい?
ではなんと言ったらわかりやすい?
345デフォルトの名無しさん
2020/12/25(金) 17:26:45.87ID:UA1/tVeu 共通するコードをライブラリ化して共有でいいんじゃないの
346デフォルトの名無しさん
2020/12/25(金) 17:48:04.91ID:tkA/KKSW バッと来て
グッと溜めて
ブワッ!
グッと溜めて
ブワッ!
347デフォルトの名無しさん
2020/12/25(金) 18:29:51.37ID:AIeBZh27 >>345
長いので1単語にまとめて
長いので1単語にまとめて
348デフォルトの名無しさん
2020/12/25(金) 19:21:45.07ID:uurLZNKt349デフォルトの名無しさん
2020/12/25(金) 19:30:34.79ID:UA1/tVeu 以前は asp.net は Windows Server でしか動かなかったからなぁ
今でこそようやく Linux でもまよもに動くようになって2年ぐらい?
twitter でも .net core で検索すると
一年前はほんと大して結果なかった気がするけど
最近は増えてきてるかな
まだまだこれからでしょ
今でこそようやく Linux でもまよもに動くようになって2年ぐらい?
twitter でも .net core で検索すると
一年前はほんと大して結果なかった気がするけど
最近は増えてきてるかな
まだまだこれからでしょ
350デフォルトの名無しさん
2020/12/25(金) 20:54:05.41ID:pgbI6Wzr >>348
あちらのほうってなんだよ
エンジニアならもっとはっきりかけよ
JSのbackendのweb frameworkか?
ろくなのないって俺が何度も書いてる。試す価値なし。
疑うなら自分で試してベンチマークとかとれよ
RailsもNode backendも遅くてゴミ
スクリプトは遅い。開発の生産性が低い
これは開発者の常識
高速なハードとソフトを合わせないとスケールするサイトにできない
あちらのほうってなんだよ
エンジニアならもっとはっきりかけよ
JSのbackendのweb frameworkか?
ろくなのないって俺が何度も書いてる。試す価値なし。
疑うなら自分で試してベンチマークとかとれよ
RailsもNode backendも遅くてゴミ
スクリプトは遅い。開発の生産性が低い
これは開発者の常識
高速なハードとソフトを合わせないとスケールするサイトにできない
351デフォルトの名無しさん
2020/12/25(金) 20:56:57.60ID:pgbI6Wzr >>349
昔はLinuxでというかライセンス無料で使えなかったのは大きいね。
JSやってるやつらはいまだにIIS, Windowsでしか動かないと思ってる。
あとclassic ASP時代のイメージのままの人も多い
昔はLinuxでというかライセンス無料で使えなかったのは大きいね。
JSやってるやつらはいまだにIIS, Windowsでしか動かないと思ってる。
あとclassic ASP時代のイメージのままの人も多い
352デフォルトの名無しさん
2020/12/25(金) 21:08:02.22ID:pgbI6Wzr 高速なコードで作りたかったらstaticに限る。
主要OSの主要な言語はstaticだ
Swift, Kotlin, Java
server-sideでKotlinもあり。
主要OSの主要な言語はstaticだ
Swift, Kotlin, Java
server-sideでKotlinもあり。
353デフォルトの名無しさん
2020/12/25(金) 23:41:23.33ID:Z26lwPgE サーバーとクライアントは同じ言語の方がいいんだろ?
354デフォルトの名無しさん
2020/12/26(土) 00:06:30.37ID:w6CJ0JU3 >>353
できれば同じ方がいいがパフォーマンスも生産性も低いJSに合わせるのは愚策
server-sideでJS使ってるのはアホだと思う
大手ならserver-sideとclient-sideは別の人材が開発するのだから
言語を合わせるメリットはあまりない
ヤフーとかもbackendでnode.js使ってるが事故ばかり起こしてるだろ
レベルが低い
できれば同じ方がいいがパフォーマンスも生産性も低いJSに合わせるのは愚策
server-sideでJS使ってるのはアホだと思う
大手ならserver-sideとclient-sideは別の人材が開発するのだから
言語を合わせるメリットはあまりない
ヤフーとかもbackendでnode.js使ってるが事故ばかり起こしてるだろ
レベルが低い
355デフォルトの名無しさん
2020/12/26(土) 19:37:00.30ID:5ukh9MxR 日本人の誰かBlazorのwikiを作ってくれ
フリーでオープンソースのウェブフレームワークって書くだけでも
wikiがないとBlazorが何かわからん
なぜC#を使ってウェブアプリが作れるのか?
ウェブブラウザはC#を解釈しないからJavaScriptとHTMLだろ
フリーでオープンソースのウェブフレームワークって書くだけでも
wikiがないとBlazorが何かわからん
なぜC#を使ってウェブアプリが作れるのか?
ウェブブラウザはC#を解釈しないからJavaScriptとHTMLだろ
356デフォルトの名無しさん
2020/12/26(土) 19:44:30.35ID:T66JFeJq BlazorWasmのほう?
WebAssemblyで調べたらいいのでは
WebAssemblyで調べたらいいのでは
357デフォルトの名無しさん
2020/12/26(土) 19:54:05.69ID:5ukh9MxR >>356
WebAssemblyはwikiがあるが本文にBlazorがない
WebAssemblyはwikiがあるが本文にBlazorがない
358デフォルトの名無しさん
2020/12/26(土) 20:13:39.65ID:q2RopqqH 所詮その程度のオモチャということです
359デフォルトの名無しさん
2020/12/26(土) 20:19:52.51ID:zr3CHg45 WebAssemblyはそれようの仮想マシンで動くからじゃないの
C#コードをその中間言語にコンパイルするだけ
たぶん
C#コードをその中間言語にコンパイルするだけ
たぶん
360デフォルトの名無しさん
2020/12/27(日) 11:16:47.49ID:FLSM18Bj >>355
そんなwiki作っても内容古くなるし意味ない
不正確で古い情報入手してどうする?
英語でMSのドキュメント読みなされ
何度も言うけどBlazorと書くべきじゃない。
Blazor Server, Blazor WebAssemblyで
アーキテクチャが全く違う。
そんなwiki作っても内容古くなるし意味ない
不正確で古い情報入手してどうする?
英語でMSのドキュメント読みなされ
何度も言うけどBlazorと書くべきじゃない。
Blazor Server, Blazor WebAssemblyで
アーキテクチャが全く違う。
361デフォルトの名無しさん
2020/12/27(日) 11:17:34.43ID:FLSM18Bj362デフォルトの名無しさん
2020/12/27(日) 11:17:38.77ID:l7B3kP+i >>360
似てるよ。
似てるよ。
363デフォルトの名無しさん
2020/12/27(日) 11:44:29.13ID:Y/0KLGYh364デフォルトの名無しさん
2020/12/27(日) 11:56:13.46ID:l7B3kP+i365デフォルトの名無しさん
2020/12/27(日) 12:57:58.03ID:5MC+7bSJ366デフォルトの名無しさん
2020/12/27(日) 14:19:59.57ID:iruxp8RS .NET6でAOTが入る予定らしいがファイルサイズの問題とかあるしwasm書くような用途なら他の言語の方がいいんじゃね
367デフォルトの名無しさん
2020/12/28(月) 12:55:53.75ID:Ov8uGTUf 状態管理ってどうやるのが無難なのかな?
blazor + fluxor ?
blazor + fluxor ?
368デフォルトの名無しさん
2020/12/28(月) 20:34:30.42ID:N8gr0T4H 状態管理サービスをDI
369デフォルトの名無しさん
2020/12/28(月) 20:36:55.85ID:RNhofGKy blazorserver ならセッション?
webassemblyならいる?
webassemblyならいる?
370デフォルトの名無しさん
2020/12/28(月) 23:32:18.60ID:w2tkTAcI GO + wasm が来年のトレンドだと思いましゅ
371デフォルトの名無しさん
2020/12/29(火) 01:03:32.89ID:QFieIEDm Kotlinはブーム来てる
Kotlinはwasmもすでに存在するようだ
Kotlinはwasmもすでに存在するようだ
372デフォルトの名無しさん
2020/12/29(火) 07:55:55.72ID:iWtJxFHh wasmとserver
wasmの方が人気だよなあ
serverはwebformの移植用以外は使い道がないんだろうか
wasmの方が人気だよなあ
serverはwebformの移植用以外は使い道がないんだろうか
373デフォルトの名無しさん
2020/12/29(火) 09:17:54.01ID:8biyF2ED go + wasm で使えるイケてるフロントエンドフレームワークがあったらいいんだがなぁ。
374デフォルトの名無しさん
2020/12/29(火) 09:43:58.26ID:QFieIEDm Googleが採用言語を分裂させすぎだから
Goは普及しないだろ
FlutterではDart
AndroidではKotlin推してる
全部Goにしてたら結果は違ったはず
Kotlinのが流行ってるしな
Go速いらしいけど人気ないのははハードル高いんだろうか
Goは普及しないだろ
FlutterではDart
AndroidではKotlin推してる
全部Goにしてたら結果は違ったはず
Kotlinのが流行ってるしな
Go速いらしいけど人気ないのははハードル高いんだろうか
375デフォルトの名無しさん
2020/12/29(火) 12:10:38.95ID:TrPJjXJg >>372
これホント?
なんとかC#しか使えないエンジニアを有効活用して
JSの10倍遅くても問題ないからオフラインでも使えるWebアプリを作りたいってニーズある?
JSが不要になるわけじゃないし現状はデスクトップアプリかblazor serverのほうが何倍も良いと思うけど
これホント?
なんとかC#しか使えないエンジニアを有効活用して
JSの10倍遅くても問題ないからオフラインでも使えるWebアプリを作りたいってニーズある?
JSが不要になるわけじゃないし現状はデスクトップアプリかblazor serverのほうが何倍も良いと思うけど
376デフォルトの名無しさん
2020/12/29(火) 12:22:03.72ID:gscEc512 PlayStation Portable go の運命と重なる...
377デフォルトの名無しさん
2020/12/29(火) 12:30:16.56ID:iAxs8NN4378デフォルトの名無しさん
2020/12/29(火) 12:33:17.29ID:Fq3XcUlo >>375
おっしゃるとおり!
俺のような企業向けアプリしか作らない人間からすると
wasmよりserverのほうが使えそうなんだよね
でもblazorでググるとwasmの記事ばかり引っかからない?
あっちのほうが期待されてるように感じる…
おっしゃるとおり!
俺のような企業向けアプリしか作らない人間からすると
wasmよりserverのほうが使えそうなんだよね
でもblazorでググるとwasmの記事ばかり引っかからない?
あっちのほうが期待されてるように感じる…
379デフォルトの名無しさん
2020/12/29(火) 13:01:36.23ID:k23+wtCh Chromeではある程度可能だが、いまのところ、広く一般には、Wasmは、ローカルファイルシステムになかなか自由にはアクセスできない。
ところが、Cordovaはlocal http serverをアプリ起動時に立ち上げて、
WebViewでHtml+JS+Wasmを起動ですることによって、
Wasm
--> JS
--> XmlHttpRequest()/fetch() で "http://localhost:5000/機能名?トークン&パラメータ" にアクセス
--> Http プロトコルの Http Request が発生し、local http serverが眠りから覚める。
--> local http server は、端末の API を好きなように呼び出し、端末の
ローカルファイルシステムを読み書きする。
--> http response で結果を JS 側に返す。
--> JS は、結果を受け取る。
の順序でWasmからローカルファイルシステムにアクセスできる様になるらしい。
Cordovaは、AndroidでWasmが使えたという報告があるし、
iOSでもVer11以降だとWasmが使えたという報告がある。
つまり、多くの人が使っているモバイルデバイスでは、WasmとCordovaの組み合わせで
モバイルのローカルファイルシステムも、あらゆる端末機能にもWasmから利用可能に
なるようだ。
ところが、Cordovaはlocal http serverをアプリ起動時に立ち上げて、
WebViewでHtml+JS+Wasmを起動ですることによって、
Wasm
--> JS
--> XmlHttpRequest()/fetch() で "http://localhost:5000/機能名?トークン&パラメータ" にアクセス
--> Http プロトコルの Http Request が発生し、local http serverが眠りから覚める。
--> local http server は、端末の API を好きなように呼び出し、端末の
ローカルファイルシステムを読み書きする。
--> http response で結果を JS 側に返す。
--> JS は、結果を受け取る。
の順序でWasmからローカルファイルシステムにアクセスできる様になるらしい。
Cordovaは、AndroidでWasmが使えたという報告があるし、
iOSでもVer11以降だとWasmが使えたという報告がある。
つまり、多くの人が使っているモバイルデバイスでは、WasmとCordovaの組み合わせで
モバイルのローカルファイルシステムも、あらゆる端末機能にもWasmから利用可能に
なるようだ。
380デフォルトの名無しさん
2020/12/29(火) 13:02:15.95ID:EHaGj/ct そりゃ技術的に面白いのはwasmだから話題になるのそっちだよ
381デフォルトの名無しさん
2020/12/29(火) 13:07:56.98ID:k23+wtCh >>379
[補足]
この方式だと端末内の他のアプリからでも、このアプリのlocal http serverに
アクセスできるからセキュリティー的な問題が有るという心配が有るかもしれないが、
そこは「トークン」をつけているので心配が無い。
それは、アプリ起動時に乱数の様なものから作成し、local http serverとJSの
両方に同じトークン値を渡すことで、鍵の様な働きをする。
トークンが合わなければlocal http serverは機能しないようにすることで、
セキュリティー上の問題はクリアできる。
[補足]
この方式だと端末内の他のアプリからでも、このアプリのlocal http serverに
アクセスできるからセキュリティー的な問題が有るという心配が有るかもしれないが、
そこは「トークン」をつけているので心配が無い。
それは、アプリ起動時に乱数の様なものから作成し、local http serverとJSの
両方に同じトークン値を渡すことで、鍵の様な働きをする。
トークンが合わなければlocal http serverは機能しないようにすることで、
セキュリティー上の問題はクリアできる。
382デフォルトの名無しさん
2020/12/29(火) 13:19:00.27ID:k23+wtCh MonacaはCordovaアプリをブラウザから作製できるようにした「クラウドIDE」で
Mac実機無しにiOSアプリを作製してAppStoreに登録できる、とされている。
Mac実機無しにiOSアプリを作製してAppStoreに登録できる、とされている。
383デフォルトの名無しさん
2020/12/29(火) 13:21:34.09ID:k23+wtCh >>382
ただし、クラウドの先にあるMac実機をレンタルする必要があるかもしれない。
ただし、クラウドの先にあるMac実機をレンタルする必要があるかもしれない。
384デフォルトの名無しさん
2020/12/30(水) 19:23:50.60ID:+vZt7ZP1385デフォルトの名無しさん
2020/12/31(木) 14:25:23.04ID:hpqEd6nD >>384
この話は、Html+JS+WasmのWebアプリWを、WebViewを使って、
native アプリAのようにする場合の話。
native アプリAが起動するときに、まずトークンTを作り、
WebViewとHttpServerを同時に起動し、その両方に同じトークンTを
渡す。
nativeアプリA
--->トークンT作製
---> HttpServerを起動しトークンTを渡す。
---> WebViewを起動しトークンTを渡す。
---> WebView内でHtml+JS+Wasm (W)が動作し始める。
---> JS内からトークンTをGET PARAMETERに付けたURLによって
fetch, または、XHRを使ってHttpServerにアクセスする。
URLは、http://localserver:5000/機能名?トークンT&パラメータ
のようになる。
---> HttpServerは、イベントを待機した状態から目覚め、
GET PARAMETERにトークンTが入っていることを確認したら、
機能名に応じた動作を nativeAPIを使って行う。
---> 端末のローカルファイルシステムにも読み書きできる。
---> 結果を Http プロトコルの Http Response で JS に返す。
---> JS は結果を受け取る。
この話は、Html+JS+WasmのWebアプリWを、WebViewを使って、
native アプリAのようにする場合の話。
native アプリAが起動するときに、まずトークンTを作り、
WebViewとHttpServerを同時に起動し、その両方に同じトークンTを
渡す。
nativeアプリA
--->トークンT作製
---> HttpServerを起動しトークンTを渡す。
---> WebViewを起動しトークンTを渡す。
---> WebView内でHtml+JS+Wasm (W)が動作し始める。
---> JS内からトークンTをGET PARAMETERに付けたURLによって
fetch, または、XHRを使ってHttpServerにアクセスする。
URLは、http://localserver:5000/機能名?トークンT&パラメータ
のようになる。
---> HttpServerは、イベントを待機した状態から目覚め、
GET PARAMETERにトークンTが入っていることを確認したら、
機能名に応じた動作を nativeAPIを使って行う。
---> 端末のローカルファイルシステムにも読み書きできる。
---> 結果を Http プロトコルの Http Response で JS に返す。
---> JS は結果を受け取る。
386デフォルトの名無しさん
2020/12/31(木) 14:45:37.85ID:tdaLm2s5 ネイティブアプリならそのままローカルファイルアクセスしてUIレイヤーとしてWebView使えば十分では?
わざわざローカルでweb server起動してそれ経由でファイルアクセスさせるメリットってあるの?
わざわざローカルでweb server起動してそれ経由でファイルアクセスさせるメリットってあるの?
387デフォルトの名無しさん
2020/12/31(木) 14:52:50.53ID:bz8vpTSU でも、既 存のア プリの流 用なら単にserverとclientを一箇所で動かすだけに見えるし、
新 規ならそもそもメ リ ットがどこにあるんだろうという感じだし。
どうしてもUIをhtmlとjsで書きたい場合とかかな。
新 規ならそもそもメ リ ットがどこにあるんだろうという感じだし。
どうしてもUIをhtmlとjsで書きたい場合とかかな。
388デフォルトの名無しさん
2021/01/01(金) 02:03:52.73ID:y/yrEKhd389デフォルトの名無しさん
2021/01/01(金) 02:09:02.70ID:y/yrEKhd390デフォルトの名無しさん
2021/01/01(金) 13:36:41.38ID:xBl+DmmI FileとかOS API使いたければ素直にnative appにするほうがいい。
わざわざwasmとか意味不明
わざわざwasmとか意味不明
391デフォルトの名無しさん
2021/01/01(金) 23:29:42.24ID:TX7qBddY392デフォルトの名無しさん
2021/01/01(金) 23:57:03.96ID:ifweq93H トークン作るネイティブアプリがあって
HttpServer側のローカルアクセス部分も個別に作るのか
HttpServer側のローカルアクセス部分も個別に作るのか
393デフォルトの名無しさん
2021/01/02(土) 00:01:46.88ID:TBL/2gAq ?
wasmからファイルにアクセスするわけじゃないよね?
というかそもそもwasmでコーディングするわけでもないよね。
wasmからファイルにアクセスするわけじゃないよね?
というかそもそもwasmでコーディングするわけでもないよね。
394デフォルトの名無しさん
2021/01/02(土) 00:47:26.18ID:md7DJnNn そもそもWasmでファイルアクセスできたらセキュリティ上おかしいんじゃないのか?
Wasmはソースコード見えないというのに
知らないうちにファイルアクセスするコードダウンロードして
実行されたらまずいだろう
MSの人も動画でBlazor Wasmは安全だといっていた。
Browserのsandbox内で動作するからというがその理由。
>>391
実際コード書いてないわけでしょ
wasmより絶対にネイティブのが楽
nativeでcross-platform対応もできる。FlutterやXamarin
Wasmはソースコード見えないというのに
知らないうちにファイルアクセスするコードダウンロードして
実行されたらまずいだろう
MSの人も動画でBlazor Wasmは安全だといっていた。
Browserのsandbox内で動作するからというがその理由。
>>391
実際コード書いてないわけでしょ
wasmより絶対にネイティブのが楽
nativeでcross-platform対応もできる。FlutterやXamarin
395デフォルトの名無しさん
2021/01/02(土) 10:59:11.61ID:kLdWoF3Z >>394
C++で書いたプログラムをWasmに変換し、それをWebViewの中で実行する場合の
話だよ。
WebViewを起動するのは、C++やSwift、Javaなど。
その際にlocal http serverとWebViewを同時に起動する。
そして1つの鍵(セキュリティートークン)をlocal http serverとWebViewの
両方に渡す。
なので安全。
C++で書いたプログラムをWasmに変換し、それをWebViewの中で実行する場合の
話だよ。
WebViewを起動するのは、C++やSwift、Javaなど。
その際にlocal http serverとWebViewを同時に起動する。
そして1つの鍵(セキュリティートークン)をlocal http serverとWebViewの
両方に渡す。
なので安全。
396デフォルトの名無しさん
2021/01/02(土) 11:26:48.47ID:XwpZ0T7a つまり、悪意のあるプログラムが自分でトークン作ってlocal http serverたたいて
それ経由でローカルファイル等の情報にアクセスできるんだろ
local http serverは正しいWebViewから呼ばれているのかどうか確認できないんだが
それのどこが安全?
それ経由でローカルファイル等の情報にアクセスできるんだろ
local http serverは正しいWebViewから呼ばれているのかどうか確認できないんだが
それのどこが安全?
397デフォルトの名無しさん
2021/01/02(土) 11:42:56.76ID:kLdWoF3Z >>396
できない。
それはキャッシュカードを拾っても、正しい暗証番号が分からなければATMから金を
引き出せないのと同じこと。
local http serverとWebViewの中のJSの両方に1つの暗証番号を渡しているので
両者だけが通信できて、他のアプリは通信できない。
できない。
それはキャッシュカードを拾っても、正しい暗証番号が分からなければATMから金を
引き出せないのと同じこと。
local http serverとWebViewの中のJSの両方に1つの暗証番号を渡しているので
両者だけが通信できて、他のアプリは通信できない。
398デフォルトの名無しさん
2021/01/02(土) 11:47:13.97ID:kLdWoF3Z >>397
[補足]
・URLのGET PARAMETERの中に正しい暗証番号(=トークン)が書いてある場合には
なるべく速く処理を行ってできるだけ早くresponseを返すようにする。
・暗証番号が間違っている時には、数秒間waitしてからresponseを返し、かつ、
waitしている間は、新たなリクエストを受け付けないようにする。
・こうすれば暗証番号を順番に試してたまたま開く鍵を見つけることが現実的な
時間では不可能になるので悪意を持ったアプリから身を守ることができる。
[補足]
・URLのGET PARAMETERの中に正しい暗証番号(=トークン)が書いてある場合には
なるべく速く処理を行ってできるだけ早くresponseを返すようにする。
・暗証番号が間違っている時には、数秒間waitしてからresponseを返し、かつ、
waitしている間は、新たなリクエストを受け付けないようにする。
・こうすれば暗証番号を順番に試してたまたま開く鍵を見つけることが現実的な
時間では不可能になるので悪意を持ったアプリから身を守ることができる。
399デフォルトの名無しさん
2021/01/02(土) 15:33:34.85ID:XwpZ0T7a いやだから、その暗証番号はカード使う人が外部から指定するんだろ
その暗証番号を指定している人が、そのカードの正しい所有者かどうか確認できないと思うんだが
これが安全だと思えないのは俺がおかしいのか?
その暗証番号を指定している人が、そのカードの正しい所有者かどうか確認できないと思うんだが
これが安全だと思えないのは俺がおかしいのか?
400デフォルトの名無しさん
2021/01/02(土) 15:35:28.24ID:kLdWoF3Z >>399
すまんが、俺のIQは、150超だから、一般プログラマには理解できないかも知れない。
すまんが、俺のIQは、150超だから、一般プログラマには理解できないかも知れない。
401デフォルトの名無しさん
2021/01/02(土) 15:46:16.27ID:5cxm5c+d InputFile の OnChange で、選択されたファイル数が0の場合はどうすればイベント拾えるのでしょうか?
<InputFile OnChange = "method" />
@code {
private void method(InputFileChangeEventArgs e)
{
//ファイル未選択の場合はこのメソッド自体が呼び出されない。
}
}
<InputFile OnChange = "method" />
@code {
private void method(InputFileChangeEventArgs e)
{
//ファイル未選択の場合はこのメソッド自体が呼び出されない。
}
}
402デフォルトの名無しさん
2021/01/02(土) 16:59:19.62ID:kLdWoF3Z >>399
WebViewという名前でも、ネット回線からダウンロードしてきた
HTML+JS+Wasmを表示・実行するわけではなく、アプリにパッケージされた
HTML+JS+Wasmを表示・実行するので、所有者の同一性は最初から保証される。
もちろんアプリのパッケージを改ざんすれば駄目だが、それは今回の
セキュリティー問題とはまた別の話。
アプリの改ざんについては、そもそも論で、それはそれで別の方法で改ざんを
防止する技術が必要となる。
WebViewという名前でも、ネット回線からダウンロードしてきた
HTML+JS+Wasmを表示・実行するわけではなく、アプリにパッケージされた
HTML+JS+Wasmを表示・実行するので、所有者の同一性は最初から保証される。
もちろんアプリのパッケージを改ざんすれば駄目だが、それは今回の
セキュリティー問題とはまた別の話。
アプリの改ざんについては、そもそも論で、それはそれで別の方法で改ざんを
防止する技術が必要となる。
403デフォルトの名無しさん
2021/01/02(土) 19:13:25.57ID:XwpZ0T7a そのアプリのパッケージにlocal http serverとサーバ側のプログラムなりスクリプトなりも含むのか?
404デフォルトの名無しさん
2021/01/02(土) 19:19:19.80ID:kLdWoF3Z >>403
アプリのパッケージには、
1. local htttp server
2. html+JS+Wasmのプログラム
3. セキュリティートークン発生器
4. ファイルAPI呼び出し器
を含む。
原則的にサーバーは全く使わないのでサーバー側プログラムは含まないが、
サーバー側プログラムを使う場合には、nativeアプリがサーバー側プログラム
と連携する場合のやり方をそのまま使えばよい。
アプリのパッケージには、
1. local htttp server
2. html+JS+Wasmのプログラム
3. セキュリティートークン発生器
4. ファイルAPI呼び出し器
を含む。
原則的にサーバーは全く使わないのでサーバー側プログラムは含まないが、
サーバー側プログラムを使う場合には、nativeアプリがサーバー側プログラム
と連携する場合のやり方をそのまま使えばよい。
405デフォルトの名無しさん
2021/01/02(土) 22:23:44.30ID:md7DJnNn >>404
通常のブラウザでは通用しないってことでOK?
ユーザーにファイルアクセスを求める仕組みはどうなってるの?
あとhttp serverなんて動かそうとしたらPCのセキュリティなりファイアウォールが警告だしてくるはず。
Flutterとかのnativeでやるほうが楽なのに
いちいちたくさんの言語使って無駄な工数かける意味がわからん。
しかもめんどくさいわりにサーバー使ってないとかますますわからん。
通常のブラウザでは通用しないってことでOK?
ユーザーにファイルアクセスを求める仕組みはどうなってるの?
あとhttp serverなんて動かそうとしたらPCのセキュリティなりファイアウォールが警告だしてくるはず。
Flutterとかのnativeでやるほうが楽なのに
いちいちたくさんの言語使って無駄な工数かける意味がわからん。
しかもめんどくさいわりにサーバー使ってないとかますますわからん。
406デフォルトの名無しさん
2021/01/02(土) 22:24:16.16ID:md7DJnNn 大手企業がWasm使ってない理由は労力のわりにメリットがないことだと思う。
メリットあるとしたらGoogle/Appleの手数料回避できそうなことくらいか
メリットあるとしたらGoogle/Appleの手数料回避できそうなことくらいか
407デフォルトの名無しさん
2021/01/03(日) 02:08:15.23ID:bUgsUhHF >>405
>通常のブラウザでは通用しないってことでOK?
ちゃんとアプリとしてパッケージしないと駄目だね。
>ユーザーにファイルアクセスを求める仕組みはどうなってるの?
ファイル関係はnativeアプリと同じになる。
なぜならnativaアプリが使うファイルAPIを使うのだから。
>あとhttp serverなんて動かそうとしたらPCのセキュリティなりファイアウォールが警告だしてくるはず。
今回説明してきた方法は、既にCordova(やmonaca)でも実績が有るのでなんとかなる
はず。AppStoreやPlayStoreなどへの登録も可能。
また、local http serverは、Rubyやnode.jsやapache、mongooseなどでも普通に
高頻度で使用されており、特にセキュリティーソフトが問題になることはない。
なぜならWasmのローカルでのテストには必ず必要になるから。
>通常のブラウザでは通用しないってことでOK?
ちゃんとアプリとしてパッケージしないと駄目だね。
>ユーザーにファイルアクセスを求める仕組みはどうなってるの?
ファイル関係はnativeアプリと同じになる。
なぜならnativaアプリが使うファイルAPIを使うのだから。
>あとhttp serverなんて動かそうとしたらPCのセキュリティなりファイアウォールが警告だしてくるはず。
今回説明してきた方法は、既にCordova(やmonaca)でも実績が有るのでなんとかなる
はず。AppStoreやPlayStoreなどへの登録も可能。
また、local http serverは、Rubyやnode.jsやapache、mongooseなどでも普通に
高頻度で使用されており、特にセキュリティーソフトが問題になることはない。
なぜならWasmのローカルでのテストには必ず必要になるから。
408デフォルトの名無しさん
2021/01/03(日) 02:15:37.37ID:bUgsUhHF >>407
[補足]
今回、local http serverは、JS+Wasmでは使えない端末機能を使うためのもの
であったが、ローカルだけでWasmを起動するためにも必要。
Wasmは、fetchやXHRを使わないと起動できないが、CORSの関係で
少なくともWindowsではlocal http serverを起動していないとエラーになる。
(それがないと、URLにローカルのファイルパスをどういうschemeで指定
しても駄目。)
[補足]
今回、local http serverは、JS+Wasmでは使えない端末機能を使うためのもの
であったが、ローカルだけでWasmを起動するためにも必要。
Wasmは、fetchやXHRを使わないと起動できないが、CORSの関係で
少なくともWindowsではlocal http serverを起動していないとエラーになる。
(それがないと、URLにローカルのファイルパスをどういうschemeで指定
しても駄目。)
409デフォルトの名無しさん
2021/01/03(日) 03:24:25.31ID:pzO8LSqN その実績ってのをいくつか紹介してくれ
410デフォルトの名無しさん
2021/01/03(日) 03:53:04.49ID:bUgsUhHF >>409
Cordovaが使っている技術を解説しているサイトに書いてある。
Cordovaを使って作るのではなく、Cordovaが自分自身で使っているアルゴリズム
であり、かつ、Cordovaは、AppStoreとPlayStoreに登録できるとされている
非常に有名なソフト。
Cordovaが使っている技術を解説しているサイトに書いてある。
Cordovaを使って作るのではなく、Cordovaが自分自身で使っているアルゴリズム
であり、かつ、Cordovaは、AppStoreとPlayStoreに登録できるとされている
非常に有名なソフト。
411デフォルトの名無しさん
2021/01/03(日) 10:07:36.68ID:ZfI7ecBk >>407
後半のlocal firewallの話は一般ユーザーの問題点だよ。
技術的に動くかどうかの話じゃない。
開発者はfirewallから警告でても意味がわかるけど、
一般ユーザーはとまどうってこと。
後半のlocal firewallの話は一般ユーザーの問題点だよ。
技術的に動くかどうかの話じゃない。
開発者はfirewallから警告でても意味がわかるけど、
一般ユーザーはとまどうってこと。
412デフォルトの名無しさん
2021/01/03(日) 10:19:49.86ID:S5x84IqF デタラメな俺理論を長々と書く奴は相手にせず放置が一番
まぁhttpdの話はローカルサーバーに同じホストからアクセスしてる分には
ファイアーウォールとか関係ないでしょ
まぁhttpdの話はローカルサーバーに同じホストからアクセスしてる分には
ファイアーウォールとか関係ないでしょ
413デフォルトの名無しさん
2021/01/03(日) 12:05:13.76ID:bUgsUhHF414デフォルトの名無しさん
2021/01/03(日) 12:06:19.30ID:bUgsUhHF415デフォルトの名無しさん
2021/01/03(日) 12:07:52.02ID:hFPMmBD/ ローカルへのhttpアクセスをデフォルトではブロックしてるファイアウォールとかもあるんだよ
416デフォルトの名無しさん
2021/01/03(日) 13:07:23.70ID:ZfI7ecBk417デフォルトの名無しさん
2021/01/03(日) 13:09:03.48ID:arRzErs6 Cordovaなんて
何年もまえからある、
弩メジャーなやつじゃん。
なので数年前に旬を過ぎて枯れてるけどね。
Visual Studioでも2013?ぐらいから
テンプレート入っとるぞ。
やっぱBlazorレベルのユーザーは
レベルが周回おくれなのか?
何年もまえからある、
弩メジャーなやつじゃん。
なので数年前に旬を過ぎて枯れてるけどね。
Visual Studioでも2013?ぐらいから
テンプレート入っとるぞ。
やっぱBlazorレベルのユーザーは
レベルが周回おくれなのか?
■ このスレッドは過去ログ倉庫に格納されています
