usergrid-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From snoopd...@apache.org
Subject incubator-usergrid git commit: Replacing Apigee, App Services and API BaaS references.
Date Mon, 03 Aug 2015 21:28:28 GMT
Repository: incubator-usergrid
Updated Branches:
  refs/heads/ug2-doc-update e17b48889 -> acae95913


Replacing Apigee, App Services and API BaaS references.


Project: http://git-wip-us.apache.org/repos/asf/incubator-usergrid/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-usergrid/commit/acae9591
Tree: http://git-wip-us.apache.org/repos/asf/incubator-usergrid/tree/acae9591
Diff: http://git-wip-us.apache.org/repos/asf/incubator-usergrid/diff/acae9591

Branch: refs/heads/ug2-doc-update
Commit: acae95913e6cefc15f3343f03418229bcde5da0d
Parents: e17b488
Author: Dave Johnson <snoopdave@apache.org>
Authored: Mon Aug 3 17:27:53 2015 -0400
Committer: Dave Johnson <snoopdave@apache.org>
Committed: Mon Aug 3 17:27:53 2015 -0400

----------------------------------------------------------------------
 .../authenticating-api-requests.md              |  6 +++---
 ...henticating-users-and-application-clients.md | 14 ++++++-------
 docs/security-and-auth/facebook-sign.md         | 22 ++++++++++----------
 .../security-and-auth/revoking-tokens-logout.md |  2 +-
 docs/security-and-auth/securing-your-app.md     |  6 +++---
 .../user-authentication-types.md                | 16 +++++++-------
 docs/security-and-auth/using-permissions.md     |  4 ++--
 7 files changed, 35 insertions(+), 35 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/incubator-usergrid/blob/acae9591/docs/security-and-auth/authenticating-api-requests.md
----------------------------------------------------------------------
diff --git a/docs/security-and-auth/authenticating-api-requests.md b/docs/security-and-auth/authenticating-api-requests.md
index c48bebd..af52bf6 100644
--- a/docs/security-and-auth/authenticating-api-requests.md
+++ b/docs/security-and-auth/authenticating-api-requests.md
@@ -1,8 +1,8 @@
 # Authenticating API requests
 
-With the exception of the 'sandbox' application that is created with every API BaaS organization,
all applications are secured by default. This means that to access your data store, a valid
access token must be sent with all API requests to authenticate that the requester is authorized
to make API calls to the resources they are attempting the access.
+With the exception of the 'sandbox' application that is created with every Usergrid organization,
all applications are secured by default. This means that to access your data store, a valid
access token must be sent with all API requests to authenticate that the requester is authorized
to make API calls to the resources they are attempting the access.
 
-This article describes how to use access tokens to access the API BaaS API, and how to manage
access tokens, including revoking and changing token time to live.
+This article describes how to use access tokens to access the Usergrid API, and how to manage
access tokens, including revoking and changing token time to live.
 
 For information on generating access tokens/authenticating users and clients, see Authenticating
users and application clients.
 
@@ -18,7 +18,7 @@ You can include the token in an HTTP authorization header:
     Authorization: Bearer {access_token}
 
 <div class="admonition note"> <p class="first admonition-title">Note</p>
<p class="last">

-Note: The API BaaS documentation assumes you are providing a valid access token with every
API call whether or not it is shown explicitly in the examples. Unless the documentation specifically
says that you can access an API endpoint without an access token, you should assume that you
must provide it. One application that does not require an access token is the sandbox application.
The Guest role has been given full permissions (/** for GET, POST, PUT, and DELETE) for this
application. This eliminates the need for a token when making application level calls to the
sandbox app. For further information on specifying permissions, see Managing access by defining
permission rules.
+Note: The Usergrid documentation assumes you are providing a valid access token with every
API call whether or not it is shown explicitly in the examples. Unless the documentation specifically
says that you can access an API endpoint without an access token, you should assume that you
must provide it. One application that does not require an access token is the sandbox application.
The Guest role has been given full permissions (/** for GET, POST, PUT, and DELETE) for this
application. This eliminates the need for a token when making application level calls to the
sandbox app. For further information on specifying permissions, see Managing access by defining
permission rules.
 </p></div>
 
 ## Authenticating with client ID and client secret

http://git-wip-us.apache.org/repos/asf/incubator-usergrid/blob/acae9591/docs/security-and-auth/authenticating-users-and-application-clients.md
----------------------------------------------------------------------
diff --git a/docs/security-and-auth/authenticating-users-and-application-clients.md b/docs/security-and-auth/authenticating-users-and-application-clients.md
index 54dded0..eaa52f4 100644
--- a/docs/security-and-auth/authenticating-users-and-application-clients.md
+++ b/docs/security-and-auth/authenticating-users-and-application-clients.md
@@ -1,6 +1,6 @@
 # Authenticating users & app clients
 
-To protect your App Services application data, one of the steps you'll take is to authenticate
your app's users. By ensuring that they are who they say they are, you can help ensure that
your application's data is available in secure ways. After you've created permission rules
that define access to your application and have associated these rules with users, you'll
want to add code that authenticates your user, as described in this topic.
+To protect your Usergrid application data, one of the steps you'll take is to authenticate
your app's users. By ensuring that they are who they say they are, you can help ensure that
your application's data is available in secure ways. After you've created permission rules
that define access to your application and have associated these rules with users, you'll
want to add code that authenticates your user, as described in this topic.
 
 <div class="admonition note"> <p class="first admonition-title">Note</p>
<p class="last">

 You manage access to your application's data by creating permission rules that govern which
users can do what. Users authenticated as Application User have access according to these
rules. For more about managing permissions, see [Using Permissions](using-permissions.html).
@@ -8,7 +8,7 @@ You manage access to your application's data by creating permission rules
that g
 
 
 ## Authentication levels
-App Services supports four levels of authentication:
+Usergrid supports four levels of authentication:
 
 * __Application user__: Grant's user access to an API Services application, based on the
roles and permissions assigned to the user.
 * __Application client__: Grants full access to perform API requests against an API Services
application.
@@ -20,10 +20,10 @@ Because the scope of access provided by the application client, organization
cli
 For a more detailed description of available authentication levels, see [Authentication levels](user-authentication-types.html).
 
 ## Application user authentication (user login)
-Using the username and password values specified when the user entity was created, your app
can connect to the App Services application endpoint to request an access token. It's also
acceptable to use the user's email address in place of the username.
+Using the username and password values specified when the user entity was created, your app
can connect to the Usergrid application endpoint to request an access token. It's also acceptable
to use the user's email address in place of the username.
 
 ### Using the SDKs
-When a user is logged in using the Apigee iOS, JavaScript, node.JS and Android SDKs, the
returned token is automatically stored in the ApigeeDataClient (iOS), DataClient (Android),
or Apigee.Client (JavaScript/node.JS) class instance, and will be sent to the API with all
subsequent method calls.
+When a user is logged in using the Usergrid iOS, JavaScript, node.JS and Android SDKs, the
returned token is automatically stored in the UsergridDataClient (iOS), DataClient (Android),
or Usergrid.Client (JavaScript/node.JS) class instance, and will be sent to the API with all
subsequent method calls.
 
 #### Request syntax
 
@@ -46,7 +46,7 @@ The results include the access token needed to make subsequent API requests
on b
     }
 		
 ## Application client authentication
-Using your app’s client id and client secret values, your app can connect to the App Services
application endpoint to request an access token. The client ID and secret for your app can
be found in 'Getting Started' section of the API Services admin portal, under 'Server App
Credentials'.
+Using your app’s client id and client secret values, your app can connect to the Usergrid
application endpoint to request an access token. The client ID and secret for your app can
be found in 'Getting Started' section of the API Services admin portal, under 'Server App
Credentials'.
 
 <div class="admonition warning"> <p class="first admonition-title">WARNING</p>
<p class="last">

 Warning: You should never authenticate this way from a client-side app such as a mobile app.
A hacker could analyze your app and extract the credentials for malicious use even if those
credentials are compiled and in binary format. See "safe mobile access" in [Authenticating
API requests](authenticating-api-requests.html) for additional considerations in keeping access
to your app and its data secure.
@@ -73,7 +73,7 @@ The results include the access token needed to make subsequent API requests
on b
     }
 		
 ## Admin user authentication
-If you do require admin user access, your app can connect to the App Services management
endpoint to request an access token. Your app supplies the username and password of an admin
user in the request.
+If you do require admin user access, your app can connect to the Usergrid management endpoint
to request an access token. Your app supplies the username and password of an admin user in
the request.
 
 <div class="admonition warning"> <p class="first admonition-title">WARNING</p>
<p class="last">

 Warning: Authenticating as an admin user grants full access to one or more organizations
and all of the applications contained in those organizations. Due to this, be cautious when
implementing this type of authentication in client-side code. Instead, consider implementing
admin user access in server-side code only. See "safe mobile access" in [Authenticating API
requests](authenticating-api-requests.html) for additional considerations in keeping access
to your app and its data secure.
@@ -100,7 +100,7 @@ The results include the access token needed to make subsequent API requests
on b
     }		    
 		
 ## Organization client authentication
-If you do require organization level access, your app can connect to the App Services management
endpoint to request an access token. Access to an organization requires the client id and
client secret credentials. The client ID and secret for your organization can be found on
the 'Org Administration' page of the API Services admin console under 'Organization API Credentials'.
+If you do require organization level access, your app can connect to the Usergrid management
endpoint to request an access token. Access to an organization requires the client id and
client secret credentials. The client ID and secret for your organization can be found on
the 'Org Administration' page of the API Services admin console under 'Organization API Credentials'.
 
 <div class="admonition warning"> <p class="first admonition-title">WARNING</p>
<p class="last">

 Warning: You should never authenticate this way from a client-side app such as a mobile app.
A hacker could analyze your app and extract the credentials for malicious use even if those
credentials are compiled and in binary format. See "safe mobile access" in [Authenticating
API requests](authenticating-api-requests.html for additional considerations in keeping access
to your app and its data secure.

http://git-wip-us.apache.org/repos/asf/incubator-usergrid/blob/acae9591/docs/security-and-auth/facebook-sign.md
----------------------------------------------------------------------
diff --git a/docs/security-and-auth/facebook-sign.md b/docs/security-and-auth/facebook-sign.md
index 55be0de..e2c7411 100644
--- a/docs/security-and-auth/facebook-sign.md
+++ b/docs/security-and-auth/facebook-sign.md
@@ -1,14 +1,14 @@
 # Facebook sign in
 
-You can authenticate your App Services requests by logging into Facebook. To access App Services
resources, you need to provide an access token with each request (unless you use the sandbox
app). You can get an access token by connecting to an appropriate web service endpoint and
providing the correct client credentials — this is further described in Authenticating users
and application clients. However, you can also obtain an access token by logging into Facebook.
+You can authenticate your Usergrid requests by logging into Facebook. To access Usergrid
resources, you need to provide an access token with each request (unless you use the sandbox
app). You can get an access token by connecting to an appropriate web service endpoint and
providing the correct client credentials — this is further described in Authenticating users
and application clients. However, you can also obtain an access token by logging into Facebook.
 
-To enable authentication to App Services through Facebook, do the following in your app:
+To enable authentication to Usergrid through Facebook, do the following in your app:
 
 1. Make a login call to the Facebook API (do this using the Facebook SDK or API). If the
login succeeds, a Facebook access token is returned.
-2. Send the Facebook access token to App Services. If the Facebook access token is valid
and the user does not already exist in App Services, App Services provisions a new App Services
user. It also returns an App Services access token, which you can use for subsequent App Services
API calls. Behind the scenes, App Services uses the Facebook access token to retrieve the
user's profile information from Facebook.
+2. Send the Facebook access token to Usergrid. If the Facebook access token is valid and
the user does not already exist in Usergrid, Usergrid provisions a new Usergrid user. It also
returns an Usergrid access token, which you can use for subsequent Usergrid API calls. Behind
the scenes, Usergrid uses the Facebook access token to retrieve the user's profile information
from Facebook.
 3. If the Facebook access token is invalid, Facebook returns an OAuth authentication error,
and the login does not succeed.
 
-The request to authenticate to App Services using a Facebook access token is:
+The request to authenticate to Usergrid using a Facebook access token is:
 
     GET https://api.usergrid.com/{my_org}/{my_app}/auth/facebook?fb_access_token={fb_access_token}
     
@@ -21,7 +21,7 @@ where:
 ## Facebook login example
 The Facebook technical guides for login present detailed information on how to add Facebook
login to your app. Instructions are provided for JavaScript, iOS, and Android.
 
-In brief, here are the steps for JavaScript. You can see these steps implemented in the Facebook
login example packaged with the JavaScript SDK for App Services (which you can download in
ZIP format or tar.gz format). The Facebook login example is in the /examples/facebook directory
of the extracted download. The code example snippets shown below are taken from the Facebook
login example.
+In brief, here are the steps for JavaScript. You can see these steps implemented in the Facebook
login example packaged with the JavaScript SDK for Usergrid (which you can download in ZIP
format or tar.gz format). The Facebook login example is in the /examples/facebook directory
of the extracted download. The code example snippets shown below are taken from the Facebook
login example.
 
 ### Step 1: Create a Facebook app
 Create a new app on the Facebook App Dashboard. Enter your app's basic information. Once
created, note the app ID shown at the top of the dashboard page.
@@ -118,11 +118,11 @@ Here is how ``FB.login()`` is implemented in the Facebook login example:
         })
       }
  
-The ``client.loginFacebook()`` function is provided by the App Services JavaScript SDK. It
uses the Facebook auth token to obtain an App Services auth token. If the Facebook access
token is valid and the user does not already exist in App Services, the function creates a
user entity for the user. It also uses the Facebook access token to retrieve the user's profile
information from Facebook.
+The ``client.loginFacebook()`` function is provided by the Usergrid JavaScript SDK. It uses
the Facebook auth token to obtain an Usergrid auth token. If the Facebook access token is
valid and the user does not already exist in Usergrid, the function creates a user entity
for the user. It also uses the Facebook access token to retrieve the user's profile information
from Facebook.
 
 Here is what the ``client.loginFacebook()`` function looks like:
 
-    Apigee.Client.prototype.loginFacebook = function (facebookToken, callback) {
+    Usergrid.Client.prototype.loginFacebook = function (facebookToken, callback) {
       var self = this;
       var options = {
         method:'GET',
@@ -136,7 +136,7 @@ Here is what the ``client.loginFacebook()`` function looks like:
         if (err && self.logging) {
           console.log('error trying to log user in');
         } else {
-          user = new Apigee.Entity('users', data.user);
+          user = new Usergrid.Entity('users', data.user);
           self.setToken(data.access_token);
         }
         if (typeof(callback) === 'function') {
@@ -145,11 +145,11 @@ Here is what the ``client.loginFacebook()`` function looks like:
       });
     }
 
-Notice that the function also returns an App Services access token, which you can use for
subsequent App Services API calls.
+Notice that the function also returns an Usergrid access token, which you can use for subsequent
Usergrid API calls.
 
-Remember to create a client for your app, which is the main entry point to the JavaScript
SDK for App Services. You need to do this before you can use the SDK. Here’s the code to
create a client:
+Remember to create a client for your app, which is the main entry point to the JavaScript
SDK for Usergrid. You need to do this before you can use the SDK. Here’s the code to create
a client:
 
-    var client = new Apigee.Client({
+    var client = new Usergrid.Client({
         orgName:'yourorgname',
         appName:'yourappname',
         logging: true, //optional - turn on logging, off by default

http://git-wip-us.apache.org/repos/asf/incubator-usergrid/blob/acae9591/docs/security-and-auth/revoking-tokens-logout.md
----------------------------------------------------------------------
diff --git a/docs/security-and-auth/revoking-tokens-logout.md b/docs/security-and-auth/revoking-tokens-logout.md
index ffbadcb..386f04f 100644
--- a/docs/security-and-auth/revoking-tokens-logout.md
+++ b/docs/security-and-auth/revoking-tokens-logout.md
@@ -3,7 +3,7 @@
 Under certain circumstances, you may need to explicitly revoke one or more tokens associated
with a user entity, such as when a user logs out of your app. This is accomplished by making
a PUT request to the /revoketoken and /revoketokens endpoints.
 
 ## Revoking tokens (user logout)
-If a user has been logged in using the Apigee iOS, Android, JavaScript or node.JS SDKs, the
returned token is automatically stored in the ApigeeDataClient (iOS), DataClient (Android),
Apigee.Client (JavaScript), Usergrid.Client (node.JS) class instance. Calling the logout method
of the SDK will destroy the token on the server, as well as in the client object.
+If a user has been logged in using the Usergrid iOS, Android, JavaScript or node.JS SDKs,
the returned token is automatically stored in the UsergridDataClient (iOS), DataClient (Android),
Usergrid.Client (JavaScript), Usergrid.Client (node.JS) class instance. Calling the logout
method of the SDK will destroy the token on the server, as well as in the client object.
 
 ### Request syntax
 

http://git-wip-us.apache.org/repos/asf/incubator-usergrid/blob/acae9591/docs/security-and-auth/securing-your-app.md
----------------------------------------------------------------------
diff --git a/docs/security-and-auth/securing-your-app.md b/docs/security-and-auth/securing-your-app.md
index 7030aef..6eb043f 100644
--- a/docs/security-and-auth/securing-your-app.md
+++ b/docs/security-and-auth/securing-your-app.md
@@ -1,9 +1,9 @@
 # Security best practices
 
-There a number of actions you should take to ensure that your app is secure before you put
it into production. The following is not an exhaustive list, but offers some common best practices
you should consider following to keep your app secure when using the API BaaS.
+There a number of actions you should take to ensure that your app is secure before you put
it into production. The following is not an exhaustive list, but offers some common best practices
you should consider following to keep your app secure when using the Usergrid.
 
 ## Never use the 'sandbox' for a production app
-By default, every new API BaaS account has an app named “sandbox” that is already created
under your new organization. This app is no different than any other app that you might create,
except that the Guest role has been given full permissions (that is, /** for GET, POST, PUT,
and DELETE). This eliminates the need for a token when making application level calls, and
can make it much easier to get your app up and running; however, it also means that any data
in the sandbox application is completely unsecured.
+By default, every new Usergrid account has an app named “sandbox” that is already created
under your new organization. This app is no different than any other app that you might create,
except that the Guest role has been given full permissions (that is, /** for GET, POST, PUT,
and DELETE). This eliminates the need for a token when making application level calls, and
can make it much easier to get your app up and running; however, it also means that any data
in the sandbox application is completely unsecured.
 
 As with any other app, you can secure the sandbox application by updating its roles and permissions.
For more on working with permissions and roles, see [Using Permissions](using-permissions.html).
 
@@ -41,4 +41,4 @@ The client secret-client id combination should be used only in secure, server-si
 ## Treat mobile clients as untrustworthy
 For mobile access, it is recommended that you connect as an application user with configured
access control policies. Mobile applications are inherently untrusted because they can be
easily examined and even decompiled.
 
-Any credentials stored in a mobile app should be considered secure only to the Application
User level. This means that if you don’t want the user to be able to access or delete data
in your API BaaS application, you need to make sure that you don’t enable that capability
through roles or permissions. Because most web applications talk to the database using some
elevated level of permissions, such as root, it’s generally a good idea for mobile applications
to connect with a more restricted set of permissions. For more information on restricting
access through permission rules, see [Using Permissions](using-permissions.html).
+Any credentials stored in a mobile app should be considered secure only to the Application
User level. This means that if you don’t want the user to be able to access or delete data
in your Usergrid application, you need to make sure that you don’t enable that capability
through roles or permissions. Because most web applications talk to the database using some
elevated level of permissions, such as root, it’s generally a good idea for mobile applications
to connect with a more restricted set of permissions. For more information on restricting
access through permission rules, see [Using Permissions](using-permissions.html).

http://git-wip-us.apache.org/repos/asf/incubator-usergrid/blob/acae9591/docs/security-and-auth/user-authentication-types.md
----------------------------------------------------------------------
diff --git a/docs/security-and-auth/user-authentication-types.md b/docs/security-and-auth/user-authentication-types.md
index 79e140f..1a14f50 100644
--- a/docs/security-and-auth/user-authentication-types.md
+++ b/docs/security-and-auth/user-authentication-types.md
@@ -1,6 +1,6 @@
 # Authentication levels
 
-App Services supports four levels of authentication, but only one of them is used when checking
a registered user's permissions. The other three levels are useful for authenticating other
application or web clients that require higher-level access to your App Services application
or organization. Because the scope of access that the other authentication levels provide
is so broad (and as a result, so powerful), it's a bad practice to use them from a mobile
app. Instead, they're better suited to other client apps, such as web applications.
+Usergrid supports four levels of authentication, but only one of them is used when checking
a registered user's permissions. The other three levels are useful for authenticating other
application or web clients that require higher-level access to your Usergrid application or
organization. Because the scope of access that the other authentication levels provide is
so broad (and as a result, so powerful), it's a bad practice to use them from a mobile app.
Instead, they're better suited to other client apps, such as web applications.
 
 ## Configuring authentication levels
 Access permissions can only be configured for the 'application user' – this can be done
both programmatically and in the admin portal. The application, organization and admin clients
cannot be configured, and can only be accessed programmatically via the API.
@@ -16,14 +16,14 @@ For more about creating and managing roles and permissions for application
users
 </tr>
 <tr>
     <td>Application user</td>
-    <td>This is the standard authentication type you will use to implement user login
for your app. The application user level allows access to your App Services application as
governed by the permission rules you create and associated with users and user groups. For
more on setting permissions see Managing access by defining permission rules. Each Application
User is represented by a User entity in your App Services application. For more about the
User entity, see User.</td>
+    <td>This is the standard authentication type you will use to implement user login
for your app. The application user level allows access to your Usergrid application as governed
by the permission rules you create and associated with users and user groups. For more on
setting permissions see Managing access by defining permission rules. Each Application User
is represented by a User entity in your Usergrid application. For more about the User entity,
see User.</td>
 </tr>
 </table>
 
 ## Admin authentication levels
 
 <div class="admonition warning"> <p class="first admonition-title">WARNING</p>
<p class="last">

-Warning: Safe use of admin authentication levels. Never use client ID and client secret,
or any hard-coded credentials to authenticate this way from a client-side app, such as a mobile
app. A hacker could analyze your app and extract the credentials for malicious use even if
those credentials are compiled and in binary format. Even when authenticating with username
and password, be cautious when using these authentication levels since they grant broad access
to your App Services account. See "safe mobile access" in Authenticating API requests for
additional considerations in keeping access to your app and its data secure.</p></div>
+Warning: Safe use of admin authentication levels. Never use client ID and client secret,
or any hard-coded credentials to authenticate this way from a client-side app, such as a mobile
app. A hacker could analyze your app and extract the credentials for malicious use even if
those credentials are compiled and in binary format. Even when authenticating with username
and password, be cautious when using these authentication levels since they grant broad access
to your Usergrid account. See "safe mobile access" in Authenticating API requests for additional
considerations in keeping access to your app and its data secure.</p></div>
 
 <table class="usergrid-table">
 <tr>
@@ -32,21 +32,21 @@ Warning: Safe use of admin authentication levels. Never use client ID
and client
 </tr>
 <tr>
    <td>Application client</td>
-   <td>Grants full access to perform any operation on an App Services application (but
not other applications within the same organization).
+   <td>Grants full access to perform any operation on an Usergrid application (but
not other applications within the same organization).
         
-   <p>Authentication at this level is useful in a server-side application (not a mobile
app) that needs access to resources through the App Services API. For example, imagine you
created a website that lists every hiking trail in the Rocky Mountains. You would want anyone
to be able to view the content, but would not want them to access the App Services API and
all your data directly. Instead, you would authenticate as an application client in your server-side
code to access the data via the API in order to serve it to your website's visitors.</p></td>
+   <p>Authentication at this level is useful in a server-side application (not a mobile
app) that needs access to resources through the Usergrid API. For example, imagine you created
a website that lists every hiking trail in the Rocky Mountains. You would want anyone to be
able to view the content, but would not want them to access the Usergrid API and all your
data directly. Instead, you would authenticate as an application client in your server-side
code to access the data via the API in order to serve it to your website's visitors.</p></td>
 </tr>
 <tr>
    <td>Organization client</td>
-   <td>Grants full access to perform any operation on an App Services organization.
+   <td>Grants full access to perform any operation on an Usergrid organization.
         
-   <p>This authentication level provides the greatest amount of access to an individual
organization, allowing a client to perform any operation on an App Services organization and
any applications in that organization. This level of access should be used sparingly and carefully.</p></td>
+   <p>This authentication level provides the greatest amount of access to an individual
organization, allowing a client to perform any operation on an Usergrid organization and any
applications in that organization. This level of access should be used sparingly and carefully.</p></td>
 </tr>
 <tr>
    <td>Admin user</td>
    <td>Allows full access to perform any operation on all organization accounts of
which the admin user is a member.
         
-   <p>This authentication level is useful from applications that provide organization-wide
administration features. For example, the App Services admin portal uses this level of access
because it requires full access to the administration features.</p>
+   <p>This authentication level is useful from applications that provide organization-wide
administration features. For example, the Usergrid admin portal uses this level of access
because it requires full access to the administration features.</p>
         
    Unless you have a specific need for administrative features, such as to run test scripts
that require access to management functionality, you should not use the admin user authentication
level.</td>
 </tr>

http://git-wip-us.apache.org/repos/asf/incubator-usergrid/blob/acae9591/docs/security-and-auth/using-permissions.md
----------------------------------------------------------------------
diff --git a/docs/security-and-auth/using-permissions.md b/docs/security-and-auth/using-permissions.md
index 092d987..34ec664 100644
--- a/docs/security-and-auth/using-permissions.md
+++ b/docs/security-and-auth/using-permissions.md
@@ -1,9 +1,9 @@
 # Using permissions
 
-Permissions allow you to define user access to perform GET, POST, PUT, or DELETE operations
on specific resources. When the user submits a request via your app code to the API BaaS API,
the user’s permissions are checked against the resource paths that the user is trying to
access. The request succeeds only if access to the resource is allowed by the permission rules
you specify.
+Permissions allow you to define user access to perform GET, POST, PUT, or DELETE operations
on specific resources. When the user submits a request via your app code to the Usergrid API,
the user’s permissions are checked against the resource paths that the user is trying to
access. The request succeeds only if access to the resource is allowed by the permission rules
you specify.
 
 ## Permissions syntax
-In API BaaS, permissions are represented in the following format:
+In Usergrid, permissions are represented in the following format:
 
     <operations>:<resource_path>
     


Mime
View raw message