Is there a role in Google appengine which only has rights to deploy the application but does not have access to data. As I understand all the roles viewer,developer and owner have access to data.
The use case is that because of security concerns many users will not want to share their data but the developers will want to give newer deployments.
Is there a way to solve this problem
I don't think it can be done with GAE admin roles. The least privileged role: viewer has the right to view the data (but not to modify it). Also don't forget that if you have a right to upload code you can upload code that will give you access to the data.
No, there is no such role. If you want to do this, you will need to give the code to your users to deploy themselves.
Note that even this doesn't solve the problem as you describe it, because the developer could trivially code in a backdoor that lets them examine the users' data. Ultimately, there is no way around this unless you're prepared to provide your source code: your users must trust you in order to use your app.
Related
Is it possible to list all of the roles that a user has access to in Snowflake DB?
I seem to be able to show the users with access to a role but I can't figure out how to list the roles a user is granted. Of course I can crawl the roles and work at it from that angle, but it would be very beneficial to do the opposite.
It turns out that:
show grants to user <user-name>;
actually lists the roles of the user. I had tried this before and misread the output and ended up wasting a lot of time looking for alternatives.
You can also use Jetty to view all roles (direct and nested) in Snowflake. It's free to use and runs locally against your native Snowflake instance.
https://docs.get-jetty.com/
Full disclosure: I am a cofounder of Jetty Labs, the company that built Jetty.
Similar questions have been asked before, but this a one is a little different. I created a REST API to send an XML document with `POST. I send data from my (Windows) application to the servers, which includes: open time, operating system, version, etc.
I have one problem though. How can I make sure people can't use the REST API? How do I know that the information sent to the server is from an application and not from someone who knows the URL? How do analytic software companies solve this problem?
Thank you.
Update
I would like users to use my application without having to log in. I am pretty sure that companies that create apps that do not force you to log in are able to see whatever you are doing.
Well there are several way to secure your service.
You can always setup authentication & authorization for the service - this way the service will be available only to registered/known users.
Here are links few links for more details:
Best Practices for securing a REST API / web service
http://www.stormpath.com/blog/secure-your-rest-api-right-way
Also there are less sophisticated ways such as setting firewall rules to allow connections only from certain places -- I don't think it is a recommended approach.
I create a CMS from scratch and decided to use CouchDB as my database solution. For my CMS I need various accounts and of course different user roles (admin, author, unregistered user, etc.).
First I thought I would program authorization within my CMS myself, but CouchDB has stuff like this build in, so I want to ask:
What is the best practice creating a multiuser app with CouchDB?
Create only one admin for CouchDB and manage restrictions, roles and accounts by yourself?
Use build-in functionality of CouchDB for all this? (Say create a CouchDB admin user for every admin of the CMS?)
What if I want to add other 3rd-party authorization later? Say I want users to login via Twitter/Facebook/Google?
Greetings,
Pipo
The critical question is whether you want to expose CouchDB to the public or not.
If you want to build your CMS as a classical 3-tier architecture where CouchDB is exclusively accessed from a privileged scripting layer, e.g. PHP, then I would recommend you to roll your own authorization system. This will give you better control over the authorization logic. Particularly, you can realize document based read access control (not available in the CouchDB security system).
If instead you want to expose CouchDB to the public, things are different. You cannot actually write server side logic (except for separate asynchronous listeners via the changes feed) so you will have to use CouchDB's built in authentication/authorization system. That limits you to read access controlled on a database level (not document level!). Write access can be controlled with validation functions. CouchDB admins should not be equivalent to application admins as a CouchDB admin is rather comparable to a server admin in a traditional setting. A database admin in CouchDB would be a better fit (can change design documents and therefore make modifications to the CMS installation like adding plugins). All other users with write access can be realized as database members.
I would prefer the second approach, because this will give you the possibility to leverage all the nice features of CouchDB like replication and the changes feed. However, you will have to do some filtered replication between databases with different members if you need fine grained read access control.
If you want to use other authentication mechanisms than those offered by CouchDB, you will eventually have to modify the installation (which can be an issue if you want to use a hosted CouchDB). For a facebook plugin see e.g. https://github.com/ocastalabs/CouchDB-Facebook-Authentication.
I am trying to develop a store locator script. May exist for WordPress however, after they are installed, no matter who logs into WordPress, each user is adding/deleting entries inside that one database of addresses.
I would like to have it so that each user belongs to a group/company. When they login to WordPress, they can only see their entries in the database.
What would be the best way to implement this?
Implement the stores as custom post types and do not give your regular users the capability edit_others_posts.
WordPress will then not show stores from other users, you don't have to do anything else.
I am developing a web based intranet for my company. I just want to know is it a good thing for users to login the application using the active directory login details or shall i create a login together with the application db.
If there is anything better that this please suggest. This is my first application development so need help from experienced people.
Generally it's a good idea to try and minimize the number of accounts people need to have.
So I'd definately try and use their active directory login.
Also if desireable, you can automatically log people into your application using various single sign on methods. (Either integrated into IIS, or other.).
This makes for a very usable application, as people always forget login details, and hate to login again to other systems.
Only use Active directory for your intranet, if you infrastructure supports it.
You question is phrased as if you think the user to type there password in again to login to the intranet site - they should not do this! have windows pass on the credentials automatically. This is pretty much built in to dotnet/iis/etc.
Also AD will add group management a privledges so you can restrict areas of you intranet to members of certain groups.
And you support team already have the tools to manage all this.
PS you can enable FireFox to auto log on via NTLM and it is one of the most requested features for Chrome too so don't let browser issues put you off
There are several pros using Active Directory authentication in the intranet.
Thoses are the main ones:
You want to to keep authentication stores number as low as possible
Using Active Directory, users who have their desktop in the domain (as they should) will be able to use Integrated Windows Authentication. They will be able to log in without having to type their password.
An Active Directory authentication mechanism probably exists for your language
More information:
http://msdn.microsoft.com/en-us/library/ms998358.aspx
If you create a separate login system, then your users have to remember 2 different logins. Why bother, when their "real" login is right at hand?
Less code for you to write and better integration into the wider system. And, who doesn't want FEWER passwords to remember.
Definitely go for the Active Directory option, or use Active Directory as an LDAP server if whatever language you're using doesn't directly support AD. Active Directory actually makes a pretty good LDAP server.
If there is anything better that this please suggest.
OpenID?...