I need to add new user roles, such as "TYPO3.Neos:Creator"
Typo3-neos Currently supported roles:"TYPO3.Neos:Editor", "TYPO3.Neos:Administrator". How can I do it?
Not sure, but it seems available roles are not stored in database, but rather are gathered from yaml configuration files (and stored in cache??).
So, add a role in any Policy.yaml file, like:
roles:
'My.Package:CreatorOfDoomRole':
privileges: []
After that you can use the flow CLI command ./flow user:addrole <username> <role> to add a new role to a user (the roles are stored as comma-separated list in table typo3_flow_security_account, field roleidentifiers).
(Some more info about how yaml is cached: "The yaml files are cached, in development context that cache should be purged on every request (and on master that's a bit optimized so they will only be flushed in development context if there was really a change to the yaml). Stored in file: Data/Temporary/Production/Configuration/ProductionConfigurations.php")
Related
I'm trying to build an intake catalog for my team. The datasets are on a shared MinIO server for which each user should have their own service account, and therefore a key/secret pair.
When creating the first catalog entry like this:
source = intake.open_netcdf(
"s3://bucket/path/to/file.netcdf",
storage_options = storage_options
)
where storage_options is a dictionary (read from a json file that the user should have in their file system) containing:
{
'key': 'KEY',
'secret': 'SECRET',
'client_kwargs': {'endpoint_url': 'http://X.X.X.X:9000'}
}
i.e. the necessary credentials for s3fs to access the MinIO server; I get a catalog entry containing the secrets:
sources:
my_dataset:
args:
storage_options:
client_kwargs:
endpoint_url: http://X.X.X.X:9000
key: KEY
secret: SECRET
urlpath: s3://bucket/path/to/file.netcdf
description: 'my description'
driver: intake_xarray.netcdf.NetCDFSource
Now this catalog file shouldn't be shared because it contains secrets, defeating the purpose of having a catalog. My question then is: how do I make the storage_options part be read from the secrets file that the user will have? (ideally without having to change from json to yaml, but it's not a requirement)
Fortunately, AWS already provides for doing this, either via environment variables or files placed in special locations ( https://boto3.amazonaws.com/v1/documentation/api/latest/guide/credentials.html#environment-variables and below).
Intake also has ways of templating values, but these ultimately end up in using the environment or getting values directly from the user. Additionally, your case is complicated by needing these values not in a top-level parameter, but nested inside storage_options. We could probably improve this system, but it would still beg the question, where should the secret values come from?
I'm currently playing around with gitlab-ce (omnibus, on an Ubuntu VM) in an environment with LDAP authentication.
The LDAP administrator recently reconfigured the OUs from something like
ou=temp, ou=users, ou=baseinfrastructure to
ou=users, ou=baseinfrastructure.
Now when I do something as simple as git pull with a regular user account, that user account will be set to ldap_blocked since gitlab queries for the user with the temp part in the cn string and obviously doesn't find it.
Is there a way to update the users or something else so gitlab no longer queries with the ou=temp, part?
After some search, I've found out the information is stored in the identities table.
In gitlab omnibus, you can start a database console using gitlab-psql.
In my case, the required query for verifying I'm doing the right thing was:
SELECT external_uid, replace(external_uid, 'ou=temp,', '') FROM identities;
and then actually replacing them by executing:
UPDATE identities SET external_uid = replace(external_uid, 'ou=temp,', '');
For a single user you can use gitlab-rails console.
Find your user:
user = User.find_by_email("user#email")
Get user extern_uid:
user.ldap_identity.extern_uid
the above should print result similar to: => "uid=username,ou=people,dc=example,dc=com"
Update values as neccesary:
user.ldap_identity.extern_uid = "uid=newusername,ou=newpeople,dc=example,dc=com"
Verify:
user.ldap_identity.extern_uid
=> "uid=newusername,ou=newpeople,dc=example,dc=com"
And finally save
user.save
I believe this script Gitlab rake task to mass update ldap dn may be useful for updating multiple users at once.
Is there a specific file or directory that is recommended for storing API keys? I'd like to take my keys out of my codebase but I'm not sure where to put them.
This is an updated answer for newer versions of Laravel.
First, set the credentials in your .env file. Generally you'll want to prefix it with the name of the service, so in this example I'll use Google Maps.
GOOGLE_KEY=secret_api_key
Then, take a look in config/services.php - it's where we can map environment variables into the app configuration. You'll see some existing examples out of the box. You can add additional configuration under the service name and point it to the environment variable.
'google' => [
'key' => env('GOOGLE_KEY'),
],
Then when you need to access this key within your app you can get it through the app configuration instead.
// Through a facade
Config::get('services.google.key');
// Through a helper
config('services.google.key');
Be sure not to just use env('GOOGLE_KEY) through your app - it's more performant to go through the app configuration as it's cached - especially if you call php artisan config:cache as part of your deployment process.
You can make your API keys environment variables and then access them that way. Read more about protecting sensitive configuration from the docs.
You simply create a .env.php file in the root of your project that returns an array of environment variables.
<?php
return array(
'SECRET_API_KEY' => 'PUT YOUR API KEY HERE'
);
Then you can access it in your app like so.
getenv('SECRET_API_KEY');
With Sonata, I'm trying to use the role based security.
I want to give a group, rights for listing, editing & creating users, so I created a role with
ROLE_MANAGE_USERS:
- ROLE_SONATA_USER_ADMIN_USER_EDIT
- ROLE_SONATA_USER_ADMIN_USER_LIST
- ROLE_SONATA_USER_ADMIN_USER_CREATE
This works fine, but according to the doc, I'm understanding that a user granted with
ROLE_SONATA_USER_STAFF
Should already inherit rights for [EDIT, LIST, CREATE], but that does not seem to be the case
I also tried with
ROLE_SONATA_USER_ADMIN_USER_STAFF
Is there something I misunderstood ?
I guess that's not the case. First of all, the name of the main roles for edit depends on the services names. For example, if the service of the admin is sonata.user.admin, then the roles will be, for example:
ROLE_SONATA_USER_ADMIN_LIST
ROLE_SONATA_USER_ADMIN_VIEW
As you can see, the prefix is always ROLE (symfony 2 requirement), followed by the service name (but having the dots exchanged with underscores, and all capital letters), and ended with the prefix for the specific permission:
LIST: view the list of objects
VIEW: view the detail of one object
CREATE: create a new object
EDIT: update an existing object
DELETE: delete an existing object
EXPORT: (for the native Sonata export links)
As I can understand, there is no ROLE_SONATA_USER_STAFF predefined for edit, list and create. However, you can define it in the hierarchy, in the security.yml file:
security:
role_hierarchy:
# Setting up
ROLE_SONATA_USER_STAFF:
- ROLE_SONATA_USER_ADMIN_EDIT
- ROLE_SONATA_USER_ADMIN_LIST
- ROLE_SONATA_USER_ADMIN_CREATE
# using the staff role to create new roles
ROLE_MANAGE_USERS: [ROLE_SONATA_USER_STAFF]
I'm working on a project where I'm trying to implement authentication against external user base for customers, this seems to be working correctly.
Recently there has been added another requirement that some people (not present in the aforementioned base) need to be able to edit parts of pages' content. First thing that comes to mind is to have separate ORM/File Auth driver enabled for those few editors to be able to authenticate them separately.
Is it possible to use two Auth drivers at the same time in Kohana 3.2?
Yes, you can use different drivers at once. Just create another instance instead of standard singleton:
// default Auth
$config = Kohana::$config->load('auth');
$auth = new Auth($config);
$user = $auth->get_user();
// special Auth for administration
$config2 = Kohana::$config->load('admin_auth');
$auth2 = new Auth($config2);
$admin = $auth2->get_user();
Restrictions:
You must use differ configs (driver and session_key values must differ). Note that some settings are defined in classes and cant be changed by config (for example, "remember" cookie named authautologin).
You cant share default ORM models (Model_User, Model_Token, Model_Role), because their names are hardcoded. But ORM driver & File driver can be used.
Kohana's Auth module does not natively support using two Drivers.
However, you can implement a new Driver yourself very easily. You can follow the instructions for creating a new Driver by copying the existing driver and modifying it, here: http://kohanaframework.org/3.3/guide/auth/driver/develop
The simple thing to do would be to put the following logic in your _login method:
Check the external user database for a valid login
If there is a valid user in the external user database, return true.
If there is no valid user in the external user database, check the local user database instead.
If the user exists in the local database, return true.