Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update nightscout #3

Merged
merged 43 commits into from
Sep 13, 2019
Merged

update nightscout #3

merged 43 commits into from
Sep 13, 2019

Conversation

g7kbr
Copy link
Owner

@g7kbr g7kbr commented Sep 13, 2019

No description provided.

PieterGit and others added 30 commits July 20, 2019 13:55
302 and 307 basically do the same thing with just one important difference:
The default 302 redirect from express.js tells the browser to repeat the request with the new URL using the GET verb.
When using the 307 status code manually, this tells the browser to repeat the very same request against the new URL using all the same parameters, headers and most important HTTP verbs.

In practice this is important every time you want to change settings or flip a switch or enter your API key (that information will never arrive at the server)
It's even more important when you get to the site through a reverse proxy that doesn't properly set the X-Forwarded-Proto header.
I've changed the explanation for the `INSECURE_USE_HTTP` environment variable.
The old first line describing this setting in just one sentence was wrong and the next line basically suggested turning this security feature off in situations where it's not needed.
In the nightscout code you check if either the connection is secure by itself or if the X-Forwarded-Proto header is set (which it should be by default in all major reverse proxy applications).
It should be unnecessary to change that setting even in a reverse proxy environment.
Perform HTTP to HTTPS redirect using 307 status
Only set INSECURE_USE_HTTP as last resort
Update browser requirements
Merge documentation change back to dev
feat: Allow Node 12 and Node 10.15.2 for Azure
…n the color view

* HIDE_CLOCK_CLOSEBUTTON setting to hide the button altogether (set to TRUE or ON to hide buttons altogether)
* Fix CSS for toolbar positioning in the main view
* Fix documentation on the clock URLs and add mention of the setting
… event that are both outside the 2-day full data load window
Load the latest 'Sensor Stop' event from last 32 days
* add support for different color prediction lines

* changed quotation marks to better fit guidelines

* corrected and standardized variable names

* added support for colored ACOB prediction and changed default prediction line colors

* added default colour for 'Values' prediction
… changed in the client. Needs expanding on later - currently only supports booleans as checkboxes.
feat: browser setting for openaps color lines
sulkaharo and others added 13 commits July 27, 2019 11:50
#4810)

* Assume any string in DISPLAY_UNITS that contains "mmol" indicates mmol and ensure mg/dl is right if the setting is not mmol

* Add startup logging for the value
* Adds data validation function to the careportal
* Validate temporary targets define both low and high target and sanitize the values for obvious issues
* Removes unused logging from openaps pill
* Fixes a bug with undefined setting
… false. When enabled, the close X always appears, 2) The views also accept this parameter from a GET parameter, which is set when navigating to the view from the menu, so users can bookmark the page without the parameter (#4824)
* Updated utils.toFixed

* tabs to spaces

* Rename the new function toFixedMin

* fix tests

* Simpler, more robust check

See https://stackoverflow.com/questions/6003884/how-do-i-check-for-null-values-in-javascript
* Use moment.js to parse dates, with better error messaging for unparseable dates

* Oops fix a bug here

* Add logging for unparseable dates

* Output a better error

* * Re-enabled heap dumps
* Improved API documentation
…denormalize UTC dates to zoned ISO dates in the API (#4826)
Updated README to reflect all changes from the release
Added a mention of INSECURE_USE_HTTP for development
… used to disable the X from appearing in the clocks at any time. The default is to show it when the GET parameter is set, allowing bookmarking a clock without the X, but retaining it when navigating to the page
This is a bug fix / improvement point release of Nightscout Jellybean

**New features**

* Adds option to colorize the OpenAPS prediction lines, along with a new mechanism for plugins to expose their extended settings to the client UI, so this setting can be switched on and off in the client
* CarePortal now validates Temporary Target values and prevents saving entries with broken data

**Changes**

* Lowers the Node version requirement to allow Azure deploys. Azure deploys are still likely to fail on free Azure tiers due to running out of hosting resources to run the site. Microsoft is looking into this and hoping to provide us a solution to hosting Nightscout in Azure, but for now if you want to upgrade to this release, you will need to use a paid Azure tier or an alternate hosting solution like Heroku (instructions on how to migrate to Heroku are to be found at nightscout.info)
* Updated documentation regarding Azure and above mentioned configuration
* **OpenAPS 0.6 users** OpenAPS 0.6 has issues with date comparison that cause the Nightscout treatment synchronization to fail for users in time zones with the relative time earlier to UTC (UTC minus something). This release adds a workaround to the system that converts dates back to the originating form in the REST API, causing the OpenAPS date comparison logic to work as expected. You can enable this workaround by setting  DE_NORMALIZE_DATES=true in Heroku / Azure.* Fixes the button positioning the toolbar
* The clock view close X button is now controlled by a parameter in the URL. If you want to bookmark a clock view without the X, open the clock view from Nightscout navigation and remove the `showClockClosebutton=true` parameter from the page address before adding the bookmark
* Latest Stop Sensor event from last 32 days is now loaded to fix some plugin issues for users who have a sensor that was started and stopped recently but more than 2 days ago

**Developers**

* Allow Node 12 in the node version checks
* Swagger REST API documentation how works over /api-docs and developer docs in CONTRIBUTING.md have been updated
@g7kbr g7kbr merged commit 01df90a into g7kbr:master Sep 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants