Currently the notification, if a sound is specified, will be converted into a critical notification. This behaviour occurs because the sideshow/apns2 package initializes a new sound-dict on `payload.SoundName()` and inserts the name into it. If the sound-key is specified as a dictionary, the alert will be seen as a critical alert according to the documentation [developer.apple.com/documentation/usernotifications](https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/generating_a_remote_notification#2943363).
In order to prevent the notification to get a critical one by specifying a sound, the sound name from the rest-API needs to be set as string to the sound-property of the payload for apns. This can be achieved by setting either the sound-key from the request to the sound property of the payload if it is a string or by setting the soundname-key from the request to the sound property without the usage of `payload.SoundName()`. For more consistency to the documentation, this pull request implements the variant, that the sound-key from the request is set as string into the sound-property of the apns-payload.
It was [not obvious](https://github.com/appleboy/gorush/issues/391) that I should specify `platform=2 (Android)` if I want to send notifications on both Android and iOS devices using Firebase, so here are some changes in documentation. Thanks!
The PushNotification object is quite big (772 bytes on AMD64),
so avoid doing too many copying without a need.
Collect pointers and do copying only when sending into a channel.
Found using https://go-critic.github.io/overview#rangeValCopy-ref
Linter output:
```
$GOPATH/src/github.com/appleboy/gorush/gorush/worker.go:38:2: rangeValCopy: each iteration copies 772 bytes (consider pointers or indexing)
$GOPATH/src/github.com/appleboy/gorush/gorush/worker.go:53:2: rangeValCopy: each iteration copies 772 bytes (consider pointers or indexing)
```
This patch simply adds `openbsd` to `TARGETS`. This is a supported Go architecture and the result will be binaries that can be run on 32 or 64-bit OpenBSD.
This project is hard to build on OpenBSD because it depends on some Linux-isms like *GNU Make* and specific `find` options. So it will be nice to have binaries easily available.
At the moment you can't start gorush with IOS base64 certificate provided using an ENV var.
Apparently viper uses default value for the configuration field even if you set env var to an empty string. So `if var is not set` or `is set and string is empty` => default value.
Which means that if I only use env vars for configuration and I want to use IOS certificate in base64 I can not set `cert_path` to an empty string, so `gorush` uses base64 cert:
https://github.com/appleboy/gorush/blob/master/gorush/notification.go#L180
I.e.:
```
ORUSH_IOS_ENABLED=true GORUSH_IOS_KEY_PATH="" GORUSH_IOS_KEY_TYPE=p12 GORUSH_IOS_KEY_BASE64="SOME_BASE64" go run main.go
(config.SectionIos) {
Enabled: (bool) true,
KeyPath: (string) (len=7) "key.pem", <--- still key.pem
KeyBase64: (string) (len=2) "SOME_BASE64",
KeyType: (string) (len=3) "p12",
Password: (string) "",
Production: (bool) false,
MaxRetry: (int) 0,
KeyID: (string) "",
TeamID: (string) ""
}
FATA[2018/06/10 - 12:42:09] certificate file does not exist
```
So by default `KeyPath` should an empty string. Then I can set only if I want.
Bo-Yi Wu
Daniel Jankowski
Belek
Dmitry Dorogin
Iskander (Alex) Sharipov
Eduard Pelesh
Stefan Arentz
sysradium