I'm playing around with the CakeDC/Users plugin and I can't for the life of me figure out how to give permission for non-logged in visitors (lets call them 'guests') to access things like my /pages/home, or if I was to do a Blog plugin, allow guests to see posts etc (but not edit).
Is this possible using the 'permissions.php' file? Seems to only work for user groups (admin and user) rather than guests? Or do I have to play around with $this->Auth->allow() and $this->Auth->deny() as in this post which seems to make the permissions.php file kinda pointless...
RBAC permissions defined in CakeDC/Users are checked in the authorization step, which means you have a user already logged in (authenticated) requesting access to a specific controller/action.
All these checks happen in the core CakePHP AuthComponent per the plugin configuration.
You want to exclude specific pages from Auth, which is something managed outside of the plugin (for now). The right way to do that is using
$this->Auth->allow('yourAction');
In the controller's beforeFilter function.
Related
I am considering to create an app for the first time and I am not sure I understand google‘s terms and conditions well. According to what I read, if I give access to some users, I will not be able to get it back and besides, google will get the right to distribute it further. Is this right?
Creating a WebApp with limited access
When you deploy a WebApp you can choose how to execute the WebApp and who has access to it:
You execute either as
You
The user accessing the App
And the App can be accessed by either
Only you
Anyone in your domain
Anyone
You are not able to select only specific users to have access.
However, obviously only the users with whom you will share the WebApp URL will have access to it.
Also, you can use within the WebApp the method getActiveUser() to retrieve the identity of the user and implement a conditional statement that runs the rest of the script only if the active user is one of the "allowed" ones.
Very important: After deploying the WebApp for the first time, you can deploy it as a new version as often as desired and change thereby the execution and access permissions which makes it easy to revoke access
i want to provide role based route access e.g there is two types of user 1.Admin and 2.normal user.
if normal user try to access admin pages through url then user will redirects to dashboard page and same case for admin.
This is quite a lot of code you're asking for.
One thing you need to look into is Route Guards which let you protect access to routes based on your own written criteria:
https://angular.io/guide/router#milestone-5-route-guards
You also need to pick a way to manage your roles and users. A popular way for Ionic is to use Firebase:
https://firebase.google.com/
A great tutorial for setting this all up is over at AngularFirebase.com (currently rebranding to Fireship.io).
It's a long tutorial, and you will need to follow an additional tutorial for setting up the login system as well, but it will get you to where you want to be.
Role Based Authorization With Firestore and Angular
I want to create a script that runs on a Google site. The script would perform a specialized calculation for a given user and then display the answer for the user. The script would depend upon user input, but the code itself should not be viewable by the user. I want the code to exist in a "black box" so that the calculation formula can be kept secret. Is this possible?
I searched the documentation, but only found this, which does not address this question:
https://developers.google.com/apps-script/guides/services/authorization#permissions_and_types_of_scripts
Whether your App script is embedded in a site or written as a standalone script does not change a lot of things... the only difference will be the way you include it on a page as a gadget.
If it is embedded it will be available from a list of scripts in the page editing, if not you'll have to use the .exec url of the deployed webapp.
Anyway, that does not change the way people will have access to the app.
You can define these parameter when you deploy the app (which is mandatory in both cases), allowing for anonymous access or requiring to be logged in.
If I understood you correctly, you would like to restrict the access to some people but not share the code.
Depending on how you defined the access mode above and wether you are using a Google Apps inside a domain or not, you will be able to do it using 2 ways :
in a domain you can get the logged user identity and use that to accept/deny showing the app.
in a "normal" gmail account you will have to implement some sort of logging feature to request a user name and password to give access to the active part of the app.
In both case you never need to share the script itself, this sharing parameter is independent from the webapp access.
I hope I understood your question correctly... if not, feel free to comment.
You might check out the Private Functions section of the following page.....the example is similar to what you're referring to, I think.
https://developers.google.com/apps-script/guides/html/communication?hl=ru
I don't fully understand how they work and haven't used them myself, but I bookmarked it to figure out later. Maybe another user who understands Private Functions better can explain...
First I apologize if I'm a dolt and am missing something obvious, but I've spent a few hours scouring documentation and am lost.
I'm trying to write a python script that will upload a bunch of images to a single user's Google Drive. The user already exists and will never change. I am not writing a web app and don't plan to use any user interface whatsoever. Everything will be done through code.
As best I can understand from the Google documentation, I have two choices:
1) Write a web app and register it to use the Drive DSK. This of course requires having urls and such for the web app.
2) Create a service account, which ties my "app" to a new service account email.
Neither of these options works for me. Is there any way to simply log in to a single user account and access their drive through python scripting?
There is a deprecated API called ClientLogin that would enable you to use the username and password for a login to access that Drive data.
But the basic idea is that you should be using something more secure -- from your users' point of view -- that allows them to authorize you without giving you their password.
For your use case it is possible that the user is you or someone you know and that you are accessing their account through a more personal kind of authorization. In that case, ClientLogin may be your best choice. If this is an application designed to be used by arbitrary users, the deprecation of ClientLogin is for a good reason and I would urge you to bite the bullet and choose one of the supported options.
The correct solution is to separate the authorization phase from the access phase. The authorization process needs to be run one time only, and can be done from a simple web site. The result of this is a refresh token which is analogous to a username/password. You will need to be aware of the security implications. Make sure you only grant drive.file scope to minimise the impact of a security breach.
Since you are uploading images, you might also want to look at the picassa api.
How can i disable or delete an user in mediawiki?
I can delete the records from the db but i am not sure if this would affect anything else in the wiki.
Any suggestions would be welcome
Thanks
Prady
1. This solutions is available out of the box for MediaWiki 1.16+
The user and all the contributed content will remain but they will not be able to log in any more.
There are two steps that need to be done:
First block the user using the link in Special Pages.
Blocking can be performed against user id or IP address to prevent them from editing the wiki.
They will still be able to log in and view content.
Then in LocalSettings.php add $wgBlockDisablesLogin=true; ($wgBlockDisablesLogin).
Now upon logging in the user will be greeted with Login error. This user is blocked. Login not allowed..
2. This solutions requires an extension that works with MediaWiki 1.29+
If you want to completely remove access to a user, e.g. on a simple private wiki, it's not possible to simply delete the account (unless no edits have been made); you can block it, but the user will still be able to read pages. However, using User Merge and Delete extension you can merge the account in another one and delete the former; the original account will then "disappear".
Also:
If you want to preserve history readability (i.e., to have edits from the user to be still shown under his name), you can create a new account e.g. with username "OriginalUserName (deactivated)" and then merge "OriginalUserName" into the former, or even use Renameuser extension.
I suppose if you wanted to revive the user later on you would need to repeat this process but this time you would merge OriginalUserName (deactivated) into OriginalUserName.
See Preventing Access page in the MediaWiki manual.
There's a special page that Admin users can see, /Special:BlockIP. Block them there.
You can also get to it from the Special Pages page, /Special:SpecialPages.
you could also reset the password of the user via
/Special:PasswordReset
note: I would not recommend deleting data via scripts in the DB. there are various functionalities for rolling back unwanted user edits, merging contribution from one user to another, etc.