常連

インフルエンサー

注目の的

社会貢献

質問力

拍手喝采

自己紹介

### 前提・実現したいこと
GatsbyJSの公式サイトチュートリアルの内容をTypeScript化しています。

表題の通り [gatsby-plugin-typegen](https://www.gatsbyjs.com/plugins/gatsby-plugin-typegen/) を使って gatsby develop すると components にあるファイルの useStaticQuery の型が消えてしまうことを防ぎたいです。
どう切り分けて考えれば良いのかわからずヒントをもらえればなと思い質問しました

### 発生している問題・エラーメッセージ
このプラグインを使うと gatsby build した際に各components(useStaticQueryを用いた)にあるファイルまたはpagesにあるファイルに使用された graphql の型を自動生成してくれます。

自動生成された型はデフォルトでは__generated__/gatsby-types.tsのファイルが作成されそこに格納されています。

しかし自動生成後、生成された型を当てはめて gatsby develop をするとなぜか components にあるファイルのgraphqlの型だけ消えてしまいます。
具体的には__generated__/gatsby-types.tsの中から型が消えてしまいます。


### gatsby developした際に生じること
下のターミナルの結果に対してコメントアウトを挿入しているようにですが、途中で型ファイルが更新後にエラーが生じます（VSCode上にて型が見つからないといった旨で怒られる）

```
gatsby-tutorial-typescript [main] ⚡  gatsby develop
error (node:56530) ExperimentalWarning: Package name self resolution is an experimental feature. This feature could change at any time
(node:56577) ExperimentalWarning: Package name self resolution is an experimental feature. This feature could change at any time
error (node:56576) ExperimentalWarning: Package name self resolution is an experimental feature. This feature could change at any time
success open and validate gatsby-configs - 0.058s
success load plugins - 5.964s
success onPreInit - 0.053s
success initialize cache - 0.027s
success copy gatsby files - 0.199s
success onPreBootstrap - 0.118s
success createSchemaCustomization - 0.009s
success Checking for changed pages - 0.001s
success source and transform nodes - 0.250s
success building schema - 0.389s
info Total nodes: 56, SitePage nodes: 3 (use --verbose for breakdown)
success createPages - 0.034s
success Checking for changed pages - 0.001s
success createPagesStatefully - 0.128s
success update schema - 0.049s
success write out redirect data - 0.016s
success Build manifest and related icons - 0.213s
success onPostBootstrap - 0.459s
info bootstrap finished - 11.722s
success onPreExtractQueries - 0.001s
//////ここら辺で型情報が上書きされて型が消える info changed file at /Users/userHoge/gatsby-tutorial-typescript/src/__generated__/gatsby-types.ts
success extract queries from components - 1.042s
//////ここら辺で型情報が上書きされて型が消える info changed file at /Users/userHoge/gatsby-tutorial-typescript/src/__generated__/gatsby-types.ts 
success write out requires - 0.193s
//////ここら辺で型情報が上書きされて型が消える info changed file at /Users/userHoge/gatsby-tutorial-typescript/src/__generated__/gatsby-types.ts
success run static queries - 0.035s - 2/2 56.72/s
success run page queries - 0.095s - 3/3 31.71/s
success onPreExtractQueries - 0.005s
success extract queries from components - 0.096s
success write out requires - 0.003s
success building schema - 0.391s
info Total nodes: 59, SitePage nodes: 6 (use --verbose for breakdown)
success createPages - 0.019s
success Checking for changed pages - 0.000s
success update schema - 0.053s
success onPreExtractQueries - 0.005s
success extract queries from components - 0.075s
success write out requires - 0.001s
info changed file at /Users/userHoge/gatsby-tutorial-typescript/src/__generated__/gatsby-types.ts
⠀
You can now view gatsby-starter-hello-world in the browser.
⠀
  http://localhost:8000/
⠀
View GraphiQL, an in-browser IDE, to explore your site's data and schema
⠀
  http://localhost:8000/___graphql
⠀
Note that the development build is not optimized.
To create a production build, use gatsby build
⠀
pathContext is deprecated. Please use pageContext instead. For migration instructions, see https://gatsby.dev/pathContext
Check the following files:
⠀
build/public/app-84fa7c1fb66eb764c29e.js
build/public/app-f4786afe15c7b54b6784.js
⠀
success Building development bundle - 6.988s
success building schema - 0.169s
info Total nodes: 59, SitePage nodes: 6 (use --verbose for breakdown)
success createPages - 0.038s
success Checking for changed pages - 0.000s
success update schema - 0.017s
success onPreExtractQueries - 0.001s
success extract queries from components - 0.043s
info changed file at /Users/userHoge/gatsby-tutorial-typescript/src/__generated__/gatsby-types.ts
success write out requires - 0.003s
success run page queries - 0.024s - 1/1 41.16/s
success building schema - 0.161s
info Total nodes: 59, SitePage nodes: 6 (use --verbose for breakdown)
success createPages - 0.014s
success Checking for changed pages - 0.000s
success update schema - 0.037s
success onPreExtractQueries - 0.003s
success extract queries from components - 0.065s
success write out requires - 0.001s
info changed file at /Users/userHoge/gatsby-tutorial-typescript/src/__generated__/gatsby-types.ts
success Re-building development bundle - 1.723s
success building schema - 0.145s
info Total nodes: 59, SitePage nodes: 6 (use --verbose for breakdown)
success createPages - 0.036s
success Checking for changed pages - 0.000s
success update schema - 0.033s
success onPreExtractQueries - 0.001s
info changed file at /Users/userHoge/gatsby-tutorial-typescript/src/__generated__/gatsby-types.ts
success extract queries from components - 0.106s
success write out requires - 0.001s
success building schema - 0.293s
info Total nodes: 59, SitePage nodes: 6 (use --verbose for breakdown)
success createPages - 0.009s
success Checking for changed pages - 0.000s
success update schema - 0.016s
success onPreExtractQueries - 0.002s
success extract queries from components - 0.032s
success write out requires - 0.000s
info changed file at /Users/userHoge/gatsby-tutorial-typescript/src/__generated__/gatsby-types.ts

/////
//これより以下は省略。success Re-building development bundle以下略が無限ループで繰り返される。
/////
```

上記のように無限ループになります。

### 試したこと
gatsby-config.jsから`gatsby-plugin-typegen`をコメントアウトするとgatsby develop が成功します。（無限ループしない）

### 補足情報（FW/ツールのバージョンなど）

strictモードは一旦外しています。


tsconfig.json
```
{
  "compilerOptions": {
    "target": "esnext",                          /* Specify ECMAScript target version: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017', 'ES2018', 'ES2019', 'ES2020', or 'ESNEXT'. */
    "module": "commonjs",                     /* Specify module code generation: 'none', 'commonjs', 'amd', 'system', 'umd', 'es2015', 'es2020', or 'ESNext'. */
    "lib": ["dom", "es2017"],                             /* Specify library files to be included in the compilation. */
    "jsx": "react",                     /* Specify JSX code generation: 'preserve', 'react-native', or 'react'. */
    "outDir": "./build",                        /* Redirect output structure to the directory. */
    "rootDir": "./",                       /* Specify the root directory of input files. Use to control the output directory structure with --outDir. */
    "noUnusedLocals": true,                /* Report errors on unused locals. */
    "noUnusedParameters": true,            /* Report errors on unused parameters. */
    "noImplicitReturns": true,             /* Report error when not all code paths in function return a value. */
    "noFallthroughCasesInSwitch": true,    /* Report errors for fallthrough cases in switch statement. */
    "baseUrl": "src",                       /* Base directory to resolve non-absolute module names. */
    "esModuleInterop": true,                  /* Enables emit interoperability between CommonJS and ES Modules via creation of namespace objects for all imports. Implies 'allowSyntheticDefaultImports'. */
    "experimentalDecorators": true,        /* Enables experimental support for ES7 decorators. */
    "emitDecoratorMetadata": true,         /* Enables experimental support for emitting type metadata for decorators. */
    "skipLibCheck": true,                     /* Skip type checking of declaration files. */
    "forceConsistentCasingInFileNames": true  /* Disallow inconsistently-cased references to the same file. */
  },
  "include": ["src/**/*", "gatsby-node/index.ts"],
  "exclude": ["node_modules", "public", "build"]
}

```

gatsby-config.js
```
module.exports = {
  siteMetadata: {
    title: `typescriptのテスト`,
    description: `これは説明文章`,
    author: `test`,
  },
  plugins: [
    `gatsby-plugin-emotion`,
    {
      resolve: `gatsby-plugin-typography`,
      options: {
        pathToConfigModule: `src/utils/typography`,
      },
    },
    {
      resolve: `gatsby-source-filesystem`,
      options: {
        name: `src`,
        path: `${__dirname}/src/`,
      }
    },
    `gatsby-transformer-remark`,
    {
      resolve: `gatsby-plugin-manifest`,
      options: {
        name: `GatsbyJS`,
        short_name: `GatsbyJS`,
        start_url: `/`,
        background_color: `#6b37bf`,
        theme_color: `#6b37bf`,
        display: `standalone`,
        icon: `src/images/icon.png`,
      },
    },
    `gatsby-plugin-offline`,
    `gatsby-plugin-react-helmet`,
    `gatsby-plugin-typegen`,
  ],
}
```

### 参考にした記事

[Gatsby.jsのTypeScript化 2020](https://zenn.dev/ryo_kawamata/articles/gatsby-ts-2020)の記事にgatsby-plugin-typegenを用いたTS化の流れが載っています。
参考までに。

gatsby-plugin-typegen を使って gatsby develop すると components にあるファイルの useStaticQueryの型が消えてしまう

以下の書き方が非推奨になりました。
```
- (void)willAnimateRotationToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation duration:(NSTimeInterval)duration
{
    ...
}
```
代わりのものを探していて、以下のものを試してみましたが、
上のものと同じタイミングでは処理を実行できませんでした。

```
- (void)viewWillTransitionToSize:(CGSize)size withTransitionCoordinator:(id<UIViewControllerTransitionCoordinator>)coordinator;
{
    ...
}
```
`willAnimateRotationToInterfaceOrientation`のときと
同じタイミングで実行されるようにしたいです。

よろしくお願いします。

Objective-C：画面の回転が検知されたときの処理

最近SPAについて勉強しています。

SPAでは、クライアントサイドレンダリングが基本だと思います。
Vue.js や React を用いてビュー部分をブラウザにわたし、サーバーサイドではAPIのみを提供しページの構築を行うと思います。

例えば、「管理者なら管理用メニュー、一般ユーザーなら普通のメニューを表示する」のようなロジックを例にすると、ビュー（ここでは Vue.js を使用すると仮定）では次のような実装が考えられると思います。

```html
<div v-if="userType === 'user'">
   	
</div>
<div v-if="userType === 'admin'">
	
</div>
```

善良なユーザーが使う分には問題無いと思いますが、悪意あるユーザーがコンソールで「userType = 'admin';」などと入力しただけで管理用メニューが表示されてしまいます。

また、そうでなくても表示されないにしろ、HTML/JSに管理用メニューの名前、及びAPIのアクセス先が書いてあるため、API側で何かしらの認証処理をするという前提があったとしても、管理用メニューにどういうものがあるのかを見られてしまうのは脆弱性につながりかねません。

このような点に関してどのような対処をするのが一般的なのでしょうか？


[追記]
皆さん、回答ありがとうございます！
質問の仕方が悪く、自分の伝えたい本質を書くことができていませんでした。

認証周りの話というよりはユーザー(ブラウザ)がコンポーネントに対する操作が可能ということに疑問を持っています。

コンソールからコンポーネントに渡すデータを変えればそのコンポーネントの挙動を変更することとが可能だと思います。

例えば入力フォームを作る場合に特定の条件のユーザーにはフォームを表示しないといったケース、
具体的にはアンケートでユーザーの会員情報で性別が女性の場合は化粧品についてのアンケートも追加で表示させるケースを考えたいと思います。

サーバーサイドレンダリングであればサーバー側でユーザーの性別を見て生成するHTMLを変更できます。

クライアントサイドレンダリングの場合は一旦全て送り、ユーザー側で非表示にさせるといった処理が考えられそうです。

ここでユーザーがコンソールから性別データをいじった場合、男性なのに化粧品のアンケートを表示させる、女性なのに化粧品のアンケートを表示させない のようなことが可能になってしまう気がします。

回答でいただいたコードスプリッティングなどで対応はできそうですが、こんな些細なものごとにいちいち分割しているとは思えません。

[追記2]
もちろんこれはSPAに限らずJavascript自体のリスクではあると思いますが、
サーバーサイドレンダリングの場合、JSは「見た目の操作」にのみ使われてることが多いと思います。
SPAではややロジックも担当している印象を受けたためこのような質問をしました。

ユーザーからの挙動変更が可能なリスクがある中でどのような策がなされているのか、あるいはなすべきなのか 教えていただきたいです。

SPA・クライアントサイドレンダリングはセキュリティ的に安全なのでしょうか？

### 前提・実現したいこと
結論からすると手間を掛けずに簡単に、匿名で報告したいです。

私とは全く関係ないとある企業のWebサイトの検索ページにXSS脆弱性を偶然にも見つけてしまったのでサイト管理者に報告したいです。

自分がWebサイトを作成する側という事もあり検索ボックスを見るとついついXSSやSQL Injectionがないかなんとなく心配になって調べてしまう事が何度かあるのですが（Webサイトの作りや雰囲気からなんとなく危なそうと感じることがある）、今回検索ボックスに「"><script>alert(1);</script>」と入れて検索すると偶然にも成功してしまいました。また、「'」を入力して検索するとHTTP 500になるのでSQL Injectionあたりも何かありそうな気がしましたがそれ以上は手を出していません。

![](bb3a7b6d3d6cdb2d0de049fe73da040c.png)

ただ、以下の点が気になっていて報告に至っていません。
- 詳しく調査した訳ではない。詳しく調査すると訴えられそう。かといって報告するには情報不足になりそうという微妙な所。
- 個人がサイト運営者に直接報告すると逆に色々因縁をつけられて訴えられる場合がある（らしい）。
- IPAのフォームから届け出を出すのが一般的（らしい）が必要項目が多いため面倒。
（たまたま見つけてしまっただけなのでそれに対して時間を掛けたくないし、御礼の言葉や対価を得ようとも思っていない。ただ単に報告したい。ちゃんと治ったかどうかは気になりますが。）
[https://isec-vul-form.ipa.go.jp/ipa-vul-main/index.html](https://isec-vul-form.ipa.go.jp/ipa-vul-main/index.html)

- サービス開始したばかりという点もありサイト管理者としては脆弱性どうこうの対応する時間がとれそうにない、対策しないという方針になれば検索ボックスそのものがなくなってしまい、通常ユーザーが被害をうけてしまいそう

- 今後もおそらく検索ボックスを見るとなんとなく脆弱性がありそうと感じることがあると思うし、その都度IPAのフォームから申請するのはしんどいので簡単に行いたいです。脆弱性を見つけてご飯を食べてる訳でもそれについて物申すことも特にしないので。。。

何かいい方法はありませんでしょうか。

XSS脆弱性を見つけてしまったので報告したい

# 概要

TypeScriptでカスタムエラーの3つの実装方法を記載しました。
自分ならXXXなのでこれを選ぶ、あるいはもっといい方法があるというようなご意見をいただきたいです。

前提条件

- **Javascript(TypeScript)では極力例外を投げるのは避けるべき**とは思っている
- サポート対象ブラウザはChrome,FireFox,Safariの最新版のみ。デバイスはPC, タブレット, スマートフォン。
- TypeScriptを使用したSPA. ソースコード50000行ほど、ファイル数680 今後2倍くらいになりそう
- フロントエンド監視にはSentryを使用している
- JavascriptのErrorを拡張して,エラー種別の判別とSentryでのバグトラッキングに活かしたい(エラーコードを設けたり、エラー種別によってエラーハンドリングを変えたり)

# 実装方法

## 1. Errorをimplementsするクラスを作成する

```
class ApplicationError implements Error {
    public name = 'ApplicationError';

    constructor(public message: string, public code: ApplicationErrorCode) { }

    toString() {
        return `${this.name}: ${this.message}`;
    }
}
```

出典 [TypeScript実践プログラミング: p195](https://books.google.co.jp/books?id=8m5qBgAAQBAJ&lpg=PP1&dq=isbn%3A4798139807&hl=ja&pg=PA195#v=onepage&q=ApplicationError&f=false)

### メリット

- アプリケーションの例外とJSの例外が分別できる

    > 引用:
    > ネイティブのError 型は聖域として扱い、この種の例外を決してスローしないようにしよう。
    > カスタム例外をApplicationError クラスのサブクラスとして作成すれば、本当に例外的な状況においてコードの外側で使用するためにError型を取っておくことができる。

### デメリット

- スタックトレースが取れない
- 子クラスを作るたびにnameを書かないといけない(何らかの方法で解決できるのかもしれないが自分は分からない)

## 2. Errorをextendsするクラスを作成する

```
class FooError extends Error {
    constructor(m: string) {
        super(m);

        // Set the prototype explicitly.
        Object.setPrototypeOf(this, FooError.prototype);
    }

    sayHello() {
        return "hello " + this.message;
    }
}
```

出典 [Extending built-ins like Error, Array, and Map may no longer work](https://github.com/Microsoft/TypeScript-wiki/blob/master/Breaking-Changes.md#extending-built-ins-like-error-array-and-map-may-no-longer-work)

### メリット

- スタックトレースが取れる

### デメリット

- `Object.setPrototypeOf` を忘れたり誤ったりすると`instance instanceof FooError`がfalseになる
- TypeScript, Javascriptの仕様変更によって壊れる可能性が1より高い(実際にTypeScript2.1で壊れた)

## 3. Errorをカスタムするのではなく,throwをカスタムしてすべてErrorを使用する

```
/**
 * フレームワークエラーを発生させます。
 *
 * @private
 * @param code {Number} エラーコード
 * @param msgParam {Any[]} フォーマットパラメータ
 * @param detail {Any} 追加のデータ(内容はAPIごとに異なる)
 */
function throwFwError(code, msgParam, detail) {

        .....

	if (code) {
		e.code = code;
	}
	if (detail) {
		e.detail = detail;
	}

	throw e;
}
```

出典 [hifive - HTML5企業Webシステムのための開発プラットフォーム - hifive](https://www.htmlhifive.com/)

### メリット

- 全てのエラーはErrorなのでインターフェースが統一されている
- codeがenumであればdiscriminated unionsによって型の推論ができる

### デメリット

- TypeScriptだとグローバルのError型定義を拡張しなければならない
- 使用する側が気を付けなければならない

TypeScriptでカスタムエラークラスを作成する方法について

```ここに言語を入力
	componentDidMount() {
		var pElement = document.getElementById( "toph" ) ;
		var clientHeight = pElement.clientHeight ;
		console.log(clientHeight);
	}
```
普通にid="toph"の高さを取得したいのですが、
実寸と取得できる数値が違います。。

実寸は100px程度なのですが、
300ぐらいの値が帰ってきます。

何か対応方法はありますでしょうか？

推測ですが、cssが当たる前の要素が縦に並んだ上体の時の
高さを引っ張ってきてるようなきがしています・・

----
追記
やりたいことはtophの高さを取得してウィンドウ高さからマイナスします。
残ったエリア内をoverflow scrollでスクロールエリアにしたく、
ブラウザの高さが変更されても再計算して常に画面に吸着した状態にすることが目的です。

----
追記2
refsを使ったやり方に変えてみましたが帰ってくる数字はまだ変わりませんでした。念のため記します。

```ここに言語を入力
	componentDidMount() {
		var test = this.refs.toph;
		console.log(test.clientHeight);
	}
  render() {
    return (
			<section>
					<div ref="toph">a<br />b</div>
					<Contents />
			</section>
    );
  }
```
tophの部分はわかりやすいように省略しました。
実寸は42pxなのですが、帰ってくる数字は48です。。。
ここに要素が入れば入るほどその数字の乖離がはげしくなっていきます・・・

---
追記3

```ここに言語を入力
	clicks() {
		var test = this.refs.toph;
		console.log(test.clientHeight);
	}
  render() {
    return (
			<section>
					<div ref="toph" onClick={this.clicks}>a<br />b</div>
					<Contents />
			</section>
    );
  }
```

このようにクリックしてから高さを取得したらちゃんとした値が取得できました。
これを読み込んだ段階で取得できると良いのですが・・・


---
追記4
```ここに言語を入力
	componentDidMount() {
		var test = this.refs.toph;
		setTimeout(function() {
			console.log(test.clientHeight);
			this.setState({hheight: test.clientHeight})
		},0)
	}
```
setTimeout0秒で入れてみるとconsole.logの部分は正しい値が表示されました！
ただ、this.setStateの部分がUncaught TypeError: this.setState is not a functionというエラーになってしまいました・・・

---
追記5
```ここに言語を入力
constructor(props) {
	super(props);
	this.state = {
		topPartsHeight: null
	};
}
componentDidMount() {
	process.nextTick(() => {
		const elem = this.topParts;
		this.setState({
			topPartsHeight: elem.clientHeight
		})
	})
}

render() {
	return (
	  <div ref={(div) => {this.topParts = div }} style={{height:this.state.topPartsHeight}}>
```
上記で実現したいことができました！みなさんありがとうございました。

react 要素の高さの取得

AWSのSESを用いて、Railsアプリケーションから一斉メール配信をしております。
週に5,6件、バウンス(メール不達)が発生しており、バウンスの検知はできております。

ただ、現状、Gmailアカウントから、対象のバウンスメールに個別送信すると、問題なく送信できるため、これまではそのような手動オペレーションをしておりました。

ただ、毎度手動でおこなうのは大変なため、SESからバウンスメールを解除し、送信できるようにしたいです。


以下のケースにおいて、対策を打ちたいと思っております。

1, 過去バウンスメールに引っかかったメールアドレス
2, 今後バウンスメールに引っかかった場合のメールアドレス

こういったことは可能でしょうか？(質問1)


また、過去のバウンスメールに引っかかったメールアドレスの傾向を把握したいと思っており、
バウンスメール一覧のようなものをAWSのCLIを使って取得できないかと思い、AWSのドキュメントを漁ってますが、見当たりません。バウンスメール一覧を取得することは可能でしょうか？(質問2)

webアプリケーション側のメールのログにstatus=bounced とともに、つぎのようなドメインが含まれていたため、outlookが起因する可能性が高いのでしょうか？(質問3)
`xxxx.mail.protection.outlook.com`

以上宜しくお願い致します。

AWSのSESにおいてバウンスメールを解除し、メール送信できるようにしたいです。（今後発生しうるメールアドレスにも対応したい）

async/awaitが利用できるようになって非同期処理の例外もキャッチできるようになりましたが、それなりの規模のアプリケーションを作成するにあたり、どのように例外処理を行えばよいか迷っています。

例えば以下はKoaを利用したウェブアプリケーションの例になりますが、catchで受け取ったエラーオブジェクトを判定してエラーの種類によって適切な処理に振り分けるようなことをするのが一般的だと認識しています。

```
const Koa = require('koa')
const app = new Koa()

app.use(async (ctx, next) => {

  try {
    await next()

  } catch(e) {

    // エラーインスタンスの種類を判定して適切に処理
    if (e instanceof TypeError ||
        e instanceof RangeError ||
        e instanceof EvalError) {
      ctx.state = 500
    }
  }
})
```
上記のように標準のエラーを振り分ける場合はこれでよいと思っているのですが「アクセス権限が無い」といったエラーを独自に作成する場合には以下のようにする必要があると思います。

```
const Koa = require('koa')
const app = new Koa()

app.use(async (ctx, next) => {

  try {
    await next()

  } catch(e) {

    // 標準エラーを適切に処理
    if (e instanceof TypeError ||
        e instanceof RangeError ||
        e instanceof EvalError) {
      ctx.state = 500

    // 認証エラーを適切に処理
    } else if (e instanceof AuthError) {
      ctx.state = 403
    }
  }
})

// --------------------------------

const AuthError = require('AuthError')

app.use((ctx, next) => {
  ...
  if( !isAdmin ) throw new AuthError()
})
```

しかし私はこのようにエラー処理を行っている例を見たことが無いので、本当にこれでよいのか不安です。

調べてみたところほとんどのサンプルではエラーを以下のように投げていました。

```
throw new Error('auth error')
```

しかしこうしてしまうとキャッチしたエラーを種類別に判定することができなくなってしまいますよね？

もちろん`e.message`の内容を利用することでエラー別に適切な処理を行うことは不可能では無いと思っていますが、エラーメッセージは同じエラーでも内容が変わってしまうことがあると思うんです。

```
// 1234の値が状況によって変わるのでe.massegeをエラー種類判定に使えない
console.log(e.message) // "user 1234 is not found"
```

そのため、エラーの種類ごとに新しいエラークラスを作成してそのインスタンスを投げる方法しかないのだろうと思っているのですが、正直なところ大量のエラークラスを作成するのは面倒な作業だなと思っています。そこで、以下のように処理してしまえばいいのでは？と思いました。

```
const Koa = require('koa')
const app = new Koa()

app.use(async (ctx, next) => {

  try {
    await next()

  } catch(e) {

    // 標準エラーを適切に処理
    if (e.name == 'TypeError' ||
        e.name == 'RangeError' ||
        e.name == 'EvalError') {
      ctx.state = 500

    // 認証エラーを適切に処理
    } else if (e.name == 'AuthError') {
      ctx.state = 403
    }
  }
})

// --------------------------------

app.use((ctx, next) => {
  ...
  if( !isAdmin ) {
    let e = new Error('auth error')
    e.name = 'AuthError'
    throw e
  }
})
```

上記の方法では```e.name```の内容を書き換える必要があるのでカスマムエラークラスを作成していた時と比較して１行でエラーをthrowすることができていた部分が４行に膨れ上がっているため若干不満ですが、それ以外は満足のいくものになりました。

よし、これでいこう！と思ったのですが、本当にこれでいいのだろうか？皆様はどのように例外処理を行なっているのだろうということが気になって前に進むことができません。

本当にこのような方法で例外処理をしてもよいのでしょうか？

例えば、このような```e.name```を書き換える方法を使って例外を投げるモジュールを作成した場合、そのモジュールが、他のプロジェクトで利用することになった場合に問題は発生しないのだろうか？という新たな疑問が発生しました。

そもそも、一般的に例外処理はどのように行えばよいのでしょうか？
検索したのですが、あまりにも記事が出てこないので質問させていただきました。

よろしくお願いいたします。

JavaScriptの例外処理の実用について

reactでログインモーダルとかポップアップをコンポーネントの外クリックすれば非表示にするみたいなUIを作る時って、クラス構文でライフサイクルメソッドにイベントリスナー設定する下のような方法以外にありますでしょうか？

https://stackoverflow.com/questions/32553158/detect-click-outside-react-component

HOCだったらこう書けるとか、v16とかだとPortal使うべきなのかなとか、その辺ざっくりな答えでもいいので詳しい方いらっしゃれば教えていただきたいです????

Reactモーダルの非表示

現在、VPS上で構築したメールサーバーでTwitterやFacebookのメールアドレス登録の際に飛んでくる確認メールだけが受け取れない状態になっています。

色々と試してみた上にTwitter社やFacebook社にも問い合わせしましたが、回答が得られず行き詰まっております。
最終的には使用するメールアドレスを独自ドメインのみとしたいと思っているため、とても困っております。

助言を頂ければと思っております。
よろしくお願いいたします。

###前提・実現したいこと
- VPS上で構成しているメールサーバーで、FacebookやTwitterのメールアドレス登録確認メールを受け取りたい
- 独自ドメインも取得しMXレコードも設定しているため、通常のメールは問題なく受信できる


###発生している問題・エラーメッセージ
- なぜかTwitterやFacebookのメールアドレス登録の際に飛んでくる確認メールだけが受け取れない状態になっている
- Postfixのログにはそもそもconnectされている様子がない


###試したこと
- gmailなどのアドレスを設定し確認メールが問題なく送られてくることを確認
- Twitter社、Facebook社へ問い合わせ（回答なし）
- firewalldを停止し確認メールを再送
- gmail等から問題なく送信できることを確認


###補足情報(言語/FW/ツール等のバージョンなど)
- OS：CentOS 7.4
- MTA：Postfix 2.10.1
- ファイアウォール：firewalld 0.4.4.4
- ドメイン：yuicho.net
- Postfixの設定上は25番と587番で平文とSTARTTLS、465番でSSLを使用できるように設定
- Firewalldに遮断するような設定はなし

Postfix で Twitter や Facebook からのメールが受け取れない

表題の通りなのですが、認証用トークン（具体的にはJWTトークン）はクッキーに保存すべきでしょうか？
ローカルストレージに保存すべきでしょうか？

クッキーに保存してリクエストヘッダーにクッキーに保存しておいたトークンを入れてリクエストを送信するといったやり方の方がセキュアでしょうか？

# 補足
前提として、ユーザーがログインに成功するとサーバー側から生成されたJWTトークンがクライアント側に送られてくるという仕様を想定しての話となります。そのトークンをクッキーに保存するべきか、もしくは、ローカルストレージに保存すべきかといった質問内容です。よろしくお願いいたします！

# 参考
https://stackoverflow.com/questions/34817617/should-jwt-be-stored-in-localstorage-or-cookie

- localStorage is subjected to XSS and generally it's not recommended to store any sensitive information in it.

- With Cookies we can apply the flag "httpOnly" which mitigates the risk of XSS. However if we are to read the JWT from Cookies on backend, we then are subjected to CSRF.


So based on the above premise - it will be best if we store JWT in Cookies. On every request to server, the JWT will be read from Cookies and added in the Authorization header using Bearer scheme. The server can then verify the JWT in the request header (as opposed to reading it from the cookies).

認証用トークンはクッキーに保存すべき？ローカルストレージに保存すべき？

Gulpでbrowserifyやbabelifyなどを使ってReactのソースをビルドしているんですが、
対象のJavaScriptファイルに単純な構文エラー(カッコが足りない、JSXの構文ミスなど)が発生すると
`gulp.watch`が止まってしまいます。

gulp-plumberを使うと継続できる、とか、
`.on('error', function(){})`でハンドリングできる、など
いくつか対策を見つけたのですが、watchが止まる状況は変わりませんでした。

Gulpの知識が無いので、記述が良くなくて効果が無いだけなのかもしれないのですが、
Gulp+Browserify+babelify+uglify+Reactな環境でエラー発生後もwatchが継続できるように
gulpfile.jsを記述したいです。

gulpfile.js
```JavaScript
gulp.task('build', function() {
	return gulp.src('src/js/*.js')
		.pipe(plumber())
		.pipe(through2.obj(function(file, encode, callback){
			browserify(file.path)
				.transform(babelify)
				.bundle(function(err, res){
						file.contents = res;
						callback(null, file)
				})
				.on('error', console.log('error'))
		}))
		.pipe(uglify({preserveComments: 'some'}))
		.pipe(gulp.dest('./build/js/'));
});
```

```JSON
  "devDependencies": {
    "babelify": "^6.3.0",
    "browser-sync": "^2.9.6",
    "browserify": "^11.2.0",
    "del": "^2.0.2",
    "gulp": "^3.9.0",
    "gulp-plumber": "^1.0.1",
    "gulp-uglify": "^1.4.1",
    "gulp-watchify": "^0.5.0",
    "react": "^0.13.3",
    "run-sequence": "^1.1.4",
    "through2": "^2.0.0",
    "vinyl-buffer": "^1.0.0",
    "vinyl-source-stream": "^1.1.0",
    "vinyl-transform": "^1.0.0"
  }
```

Gulpでエラー発生時にwatchを継続したい

Objective-Cを利用しております。

xibにてビューのパーツを作成し、利用するビューから呼び出し利用しているのですが、このビューのパーツ側のクラスに閉じる際に呼び出しを行うデリゲートメソッドを実装しています。

このメソッドの定義ですが、ふと他の方の命名規則を参考にし整理したいと考えたのですが、うまくいかない為ご助言いただければと思います。

単純に作成しますと以下のような記述が想定されます。

```example.h
@protocol ExampleViewDelegate <NSObject>

-(void) didClose;

@end
```

しかしこのような命名ですと、呼び出し側で複数のビューパーツを用いた場合混乱する可能性も考えられます。
そこで他の方の命名を参考し、第一引数に自信のビューを定義する形に変更したいとかんがえましたが、そもそも引数が存在しないと形として成り立たないように思えます。

```example.h
@protocol ExampleViewDelegate <NSObject>

-(void) ExampleView:(UIView *)ExampleView didClose;

@end
```

上記は当然エラーとなります。

このような場合はどのように命名するのがわかりやすいのでしょうか。

例えば、アイテムの追加のようなケースであれば分かりやすく、以下のような記述で問題ないと考えております。

```example.h
@protocol ExampleViewDelegate <NSObject>

-(void) ExampleView:(UIView *)ExampleView shouldAddItem:(NSString*)ItemName;

@end
```

希望としては呼び出し元の記述で混乱をきたさないような形で定義できればというのがありますが、それ以外は経験不足もあり特に意識している部分はありません。

ご助言いただけますと幸いです。

デリゲートメソッドの命名

Ajaxを学習しようと思っています。
学習する経緯は、個人で作っているWebアプリの一部の機能に使うためです。

因に私はJavaScriptをたまに使うくらいで簡単なWebアプリにJSを使ったくらいで、
またAjaxを触ったことがありません。
そこで過去にAjaxを学習する際に使ったオススメのサイトや書籍などが
あれば教えていただけますか？
