Commit Graph

6 Commits

Author SHA1 Message Date
Naz Gargol
b89b57b6fb
Added global site SEO fields in Admin API (#10923)
refs #10921

- New SEO related fields will now be available as a part of Admin API /settings endpoint
- The ordering of fields is taken from post's schema
- Extended settings test suite with new SEO fields
- Adjusted settings model unit test
2019-07-18 16:24:34 +02:00
Fabien O'Carroll
f9899cb8c4
Updated theme layer to use members-ssr (#10676)
* Removed support for cookies in members auth middleware

no-issue

The members middleware will no longer be supporting cookies, the cookie
will be handled by a new middleware specific for serverside rendering,
more informations can be found here:

https://paper.dropbox.com/doc/Members-Auth-II-4WP4vF6coMqDYbSMIajo5

* Removed members auth middleware from site app

no-issue

The site app no longer needs the members auth middleware as it doesn't
support cookies, and will be replaced by ssr specific middleware.

https://paper.dropbox.com/doc/Members-Auth-II-4WP4vF6coMqDYbSMIajo5

* Added comment for session_secret setting

no-issue

We are going to have multiple concepts of sessions, so adding a comment
here to be specific that this is for the Ghost Admin client

* Added theme_session_secret setting dynamic default

no-issue

Sessions for the theme layer will be signed, so we generate a random hex
string to use as a signing key

* Added getPublicConfig method

* Replaced export of httpHandler with POJO apiInstance

no-issue

This is mainly to reduce the public api, so it's easier to document.

* Renamed memberUserObject -> members

no-issue

Simplifies the interface, and is more inline with what we would want to export as an api library.

* Removed use of require options inside members

no-issue

This was too tight of a coupling between Ghost and Members

* Simplified apiInstance definition

no-issue

* Added getMember method to members api

* Added MembersSSR instance to members service

* Wired up routes for members ssr

* Updated members auth middleware to use getPublicConfig

* Removed publicKey static export from members service

* Used real session secret

no-issue

* Added DELETE /members/ssr handler

no-issue

This allows users to log out of the theme layer

* Fixed missing code property

no-issue

Ignition uses the statusCode property to forward status codes to call sites

* Removed superfluous error middleware

no-issue

Before we used generic JWT middleware which would reject, now the
middleware catches it's own error and doesn't error, thus this
middleware is unecessary.

* Removed console.logs

no-issue

* Updated token expirty to hardcoded 20 minutes

no-issue

This returns to our previous state of using short lived tokens, both for
security and simplicity.

* Removed hardcoded default member settings

no-issue

This is no longer needed, as defaults are in default-settings.json

* Removed stripe from default payment processor

no-issue

* Exported `getSiteUrl` method from url utils

no-issue

This keeps inline with newer naming conventions

* Updated how audience access control works

no-issue

Rather than being passed a function, members api now receives an object
which describes which origins have access to which audiences, and how
long those tokens should be allowed to work for. It also allows syntax
for default tokens where audience === origin requesting it. This can be
set to undefined or null to disable this functionality.

{
    "http://site.com": {
        "http://site.com": {
            tokenLength: '5m'
        },
        "http://othersite.com": {
            tokenLength: '1h'
        }
    },
    "*": {
        tokenLength: '30m'
    }
}

* Updated members service to use access control feature

no-issue

This also cleans up a lot of unecessary variable definitions, and some
other minor cleanups.

* Added status code to auth pages html response

no-issue

This was missing, probably default but better to be explicit

* Updated gateway to have membersApiUrl from config

no-issue

Previously we were parsing the url, this was not very safe as we can
have Ghost hosted on a subdomain, and this would have failed.

* Added issuer to public config for members

no-issue

This can be used to request SSR tokens in the client

* Fixed path for gateway bundle

no-issue

* Updated settings model tests

no-issue

* Revert "Removed stripe from default payment processor"

This reverts commit 1d88d9b6d73a10091070bcc1b7f5779d071c7845.

* Revert "Removed hardcoded default member settings"

This reverts commit 9d899048ba7d4b272b9ac65a95a52af66b30914a.

* Installed @tryghost/members-ssr

* Fixed tests for settings model
2019-04-16 16:50:25 +02:00
Fabien O'Carroll
f74d459dad Removed active and installed apps default settings
no-issue
2019-04-16 11:05:33 +02:00
Naz Gargol
c219446f85
Model regression tests cleanup (#10639)
refs #9178

- Migrated settings model regression to unit tests
- Removed redundant/unuseful post tests
- Extracted post model regression tests to API tests 
- Renamed test suites for consistency
2019-03-26 11:37:32 +08:00
kirrg001
0c8373afb7 Removed 'null' parsing in settings model
refs #10582

- I don't think this is a good idea
- If a user passses "null", we should treat it as a string
- I am not aware of a use case why people have "null" in their database
- If people send "null" via the API, we should respect this and accept a string
2019-03-11 20:07:48 +01:00
Katharina Irrgang
04c60b4ce1
🐛 Fixed private blogging getting enabled when saving any setting (#10576)
no issue

- Reported here: https://forum.ghost.org/t/in-version-2-16-3-found-bug/6065/3

---

Admin Client sends false or true booleans for `is_private` key.

The settings table has two columns "key" and "value". And "value" is always type TEXT.

If you pass value=false, the db will transform this value into "0".
`settingsCache.get('is_private')` is then always true, even though the value is meant to be false.

We should add a migration in v3 and normalize all setting values to ensure consistent database values. Furthermore, we should improve the handling around settings values in general.

For now, we protect parsing values from DB, which we anyway need to transform the values into the correct data type, because we always save strings. This will protect values being stored as "false" or "1" or whatever.
2019-03-06 12:56:26 +01:00