Admin features

[peta15]

Create a page that only admins can access that enables admins to view the visitors log, organize user accounts (view and delete users). Most importantly this will provide an example of how to create admin only areas and mark users as admins.

[coto]

Awesome. I am strongly agree

-- Rodrigo @coto On Jul 17, 2012 10:07 PM, "Jesse Goodall" < reply@reply.github.com> wrote:

Create a page that only admins can access that enables admins to view the visitors log, organize user accounts (view and delete users). Most importantly this will provide an example of how to create admin only areas and mark users as admins.

---

Reply to this email directly or view it on GitHub: https://github.com/coto/gae-boilerplate/issues/81

[kordless]

I've been thinking about this for my project. GAE provides a funciton for ID'ing users, but it's limited to logged in admins of the project:

from google.appengine.api import users

user = users.get_current_user()

if user:
    print "Welcome, %s!" % user.nickname()
    if users.is_current_user_admin():
        print "<a href=\"/admin/\">Go to admin area</a>"

One of my side projects needed a different class of user created, so I threw in a flag for ID'ing those users in the User() model:

    employer = ndb.BooleanProperty(default=False)

Perhaps a combination of Google's is_current_user_admin() method and our own would be the best approach for implimentation and control while remaining secure? I see an admin flow panning out like this:

• you log in to the site with current user/pass
• site notices you are flagged as an 'admin' in a seperate Administrator model's table
• you attempt to access admin-only features
• you are asked to log into your Google account which is associated with GAE project
• you are shown the admin interface

To ensure security, I suggest keeping the methods for adding a user as an admin to a minimum. Don't collude the 'flags' for admin priveldges with the current User model (in case there is a security issue with User methods). Limit it to a few simple methods, coupled with the two factor auth you get from also testing is_current_user_admin().

As for what I want on the admin interface (goodness knows I have reason to have opinons on this stuff!):

• performance stats: https://developers.google.com/appengine/docs/python/tools/appstats
• continous integration statuses (maybe overlayed on performance stats)
• activity charts (signups, logins, password changes, exceptions!)
• log activity for high volume users (want to manage DoS attacks, even if they are a result of bad code using my APIs)
• browsable user list (username, last login, disable/enable account)
• user detail view (everything we know about them with buttons and switches to easily manage)
• link to data store views on the GAE interface
• list of current running jobs in the queue with stop buttons
• cost for current billing cycle
• A/B split

I realize a lot of this could be addressed by something like NewRelic, but given I'm working on a framework for building a bunch of this anyway, I don't see any reason not to stuff it into the project for others.

Let's continue the discussion!

[peta15]

That would be awesome!

Yes a lot of what i would expect new relic provides is already covered in what you state below plus what exists in the google app engine admin console.

By the way has anyone been able to get the datastore admin working? I want it to be able to conveniently clear my datastore but from what i am reading it has errors running with federated login turned on. If no one knows of an easy solution we could add some utilities to our admin console to clear the datastore etc. For instance i'm creating a handler that runs some datastore commands including ndb.delete_multi(ndb.query()) which will wipe the store.

Also I'm thinking we should try to ensure the first level of authentication fits into a site wide permissioning scheme where you can perm users or groups of users for certain handlers. ie admin would be one of the groups. I've heard pyramid's traverse is excellent for something like this....

Thanks,

Jesse

On Wed, Oct 31, 2012 at 1:31 PM, Kord Campbell notifications@github.comwrote:

I've been thinking about this for my project. GAE provides a funciton for ID'ing users, but it's limited to logged in admins of the project:

from google.appengine.api import users

user = users.get_current_user()

if user: print "Welcome, %s!" % user.nickname() if users.is_current_user_admin(): print "<a href=\"/admin/\">Go to admin area"

One of my side projects needed a different class of user created, so I threw in a flag for ID'ing those users in the User() model:

employer = ndb.BooleanProperty(default=False)

Perhaps a combination of Google's is_current_user_admin() method and our own would be the best approach for implimentation and control while remaining secure? I see an admin flow panning out like this:

• you log in to the site with current user/pass
• site notices you are flagged as an 'admin' in a seperate Administrator model's table
• you attempt to access admin-only features
• you are asked to log into your Google account which is associated with GAE project
• you are shown the admin interface

To ensure security, I suggest keeping the methods for adding a user as an admin to a minimum. Don't collude the 'flags' for admin priveldges with the current User model (in case there is a security issue with User methods). Limit it to a few simple methods, coupled with the two factor auth you get from also testing is_current_user_admin().

As for what I want on the admin interface (goodness knows I have reason to have opinons on this stuff!):

• performance stats: https://developers.google.com/appengine/docs/python/tools/appstats
• continous integration statuses (maybe overlayed on performance stats)
• activity charts (signups, logins, password changes, exceptions!)
• log activity for high volume users (want to manage DoS attacks, even if they are a result of bad code using my APIs)
• browsable user list (username, last login, disable/enable account)
• user detail view (everything we know about them with buttons and switches to easily manage)
• link to data store views on the GAE interface
• list of current running jobs in the queue with stop buttons
• cost for current billing cycle
• A/B split

I realize a lot of this could be addressed by something like NewRelic, but given I'm working on a framework for building a bunch of this anyway, I don't see any reason not to stuff it into the project for others.

Let's continue the discussion!

— Reply to this email directly or view it on GitHubhttps://github.com/coto/gae-boilerplate/issues/81#issuecomment-9954093.

[peta15]

Hi @kordless, looks like @sergue1 may have gotten a head start on this. Please see his pull request/commit. It sounds like you want to add features he hasn't yet though (he has implemented only user list and user detail view out of your list). My suggestion is that you two try to coordinate a bit, at least we should assign you to this issue in the issue list so others know you are working on it.

[kordless]

Sure. Looking at the pull request now.

[peta15]

we could add a page that has a table showing log visits, clicking on column headers such as timestamp allows sorting by that column, and then we could also pull data from something like http://ip-address-lookup-v4.com/ to get location etc.

[sergue1]

+1 activity charts as mentioned by @kordless: signups today, signups this week...

[snvandoorn]

Hi guys, can this item be closed, and a new one opened for things still missing?

[coto]

alright!!