♻ Updated naming for Content API specific middleware

no-issue

This is because the Content API will eventually be accessed not just
from Content API keys. The addition of a Content API specific
authorization middleware is because:
1. content api should not authorize based on req.user
2. content api will need separate authorization than admin api

core/server/services/auth/authenticate.js

@@ -103,7 +103,7 @@ const authenticate = {
 
     // ### v2 API auth middleware
     authenticateAdminAPI: [session.safeGetSession, session.getUser],
-    authenticateContentApiKey: apiKeyAuth.content.authenticateContentApiKey
+    authenticateContentApi: apiKeyAuth.content.authenticateContentApiKey
 };
 
 module.exports = authenticate;

core/server/services/auth/authorize.js

@@ -38,7 +38,15 @@ const authorize = {
     },
 
     authorizeAdminAPI: [session.ensureUser],
-    // used by API v2 endpoints
+    authorizeContentApi(req, res, next) {
+        const hasApiKey = req.api_key && req.api_key.id;
+        if (hasApiKey) {
+            return next();
+        } else {
+            return next(new common.errors.NoPermissionError({message: common.i18n.t('errors.middleware.auth.pleaseSignInOrAuthenticate')}));
+        }
+    },
+
     requiresAuthorizedUserOrApiKey(req, res, next) {
         const hasUser = req.user && req.user.id;
         const hasApiKey = req.api_key && req.api_key.id;

core/server/web/api/v2/content/middleware.js

@@ -14,8 +14,8 @@ const shared = require('../../../shared');
  * Authentication for public endpoints
  */
 module.exports.authenticatePublic = [
-    auth.authenticate.authenticateContentApiKey,
+    auth.authenticate.authenticateContentApi,
-    auth.authorize.requiresAuthorizedUserOrApiKey,
+    auth.authorize.authorizeContentApi,
     cors(),
     shared.middlewares.urlRedirects.adminRedirect,
     shared.middlewares.prettyUrls