I am configuring a Sentry on premise installation (using the default Docker image) with LDAP authentication, so any time a user logs-in for the first time a Sentry user is created under the hood.
The default notifications settings for these new users are pretty annoying, because the Workflow Notifications flag is set to Always, and ideally we'd like it to be Only On Issues I Subscribe To.
I know that each new user can go and update their settings by hand, but this is a largish corporation and I don't want to be directing every single person to change that when they get tired of receiving too many notifications and come asking me.
So in brief: is there any way to update the default notifications settings for new Sentry users?
As a quick and dirty way to achieve this, I am applying this patch when building our custom Sentry on Premise Docker image, alongside the steps where we copy the config files.
diff --git a/src/sentry/api/endpoints/user_notification_details.py b/src/sentry/api/endpoints/user_notification_details.py
index a382b6b7e3..2edd21efc7 100644
--- a/src/sentry/api/endpoints/user_notification_details.py
+++ b/src/sentry/api/endpoints/user_notification_details.py
## -36,7 +36,7 ## USER_OPTION_SETTINGS = {
},
'workflowNotifications': {
'key': 'workflow:notifications',
- 'default': UserOptionValue.all_conversations, # '0'
+ 'default': UserOptionValue.participating_only, # '0'
'type': int,
}
}
Related
Dears,
I use Opensips 3.2
Here is my script:
store_dlg_value("is_sended_inv","0");
notify_on_event("E_UL_CONTACT_INSERT", $avp(filter), "LATE_FORKING", 45);
notify_on_event("E_UL_CONTACT_UPDATE", $avp(filter), "LATE_FORKING", 45);
...
## Handle late forking route
route[LATE_FORKING] {
# handle incoming calls for mobile devices woken up by push notifications
$var(is_sended_inv) = $dlg_val(is_sended_inv);
xlog("L_INFO", "[LATE_FORKING] [var(is_sended_inv)=$var(is_sended_inv)] New contact [$avp(uri)] registered for user [$avp(aor)], inserting new branch to ongoing call\n");
# take the contact described by the E_UL_CONTACT_INSERT
# event and inject it as a new branch into the original
# transaction
if(!$var(is_sended_inv)) {
t_inject_branches("event", "last");
xlog("L_INFO", "[LATE_FORKING] t_inject_branches event\n");
store_dlg_value("is_sended_inv","1");
}
}
When Register sent many times, t_inject_branches got called back many times, resulted in a lot of Invite sending (same CSeq number).
How can call t_inject_branches only one time when use event routing in same Dialog?
Thank you for your help.
I tried store_dlg_value
I've deployed the vanilla CouchDB Docker container, tag "latest" on DigitalOcean's App Platform.
I set the admin user using environment variables and I successfully were able to curl to the database server on https port 443, not 5984 as a raw install. Then I created the system databases as outlined in the docker documentation.
The initial load of the Fauxton UI worked (using _utils), however login fails on an UI level. The login form submits the form with name/password, CouchDB replies with:
{
"ok":true,
"name":"couchadmin",
"roles":[
"_admin"
]
}
A toast appears "You have been logged in", the AuthSession cookies gets set, but Fauxton won't let me access any function, just redirects to the login page again.
What do I miss?
Update
Checked the network tab again, there's more going on:
POST to _session, result as above
GET tp _session, result:
{"ok":true,"userCtx":{"name":null,"roles":[]},"info":{"authentication_handlers":["cookie","default"]}}
name and roles are null/empty. Then GET repeats a final time with the same result
** Update 2 **
When I query _session?basic=true I get a proper response:
{
ok: true,
userCtx: {
name: "couchadmin",
roles: [
"_admin",
"user",
"admin"
]
},
info: {
authentication_handlers: [
"cookie",
"default"
],
authenticated: "cookie"
}
}
Looks like the session cookie is eaten somewhere along the line.
In your first POST to _SESSION, can you check what response headers you get and whether it includes a session cookie?
Turns out that the cookie is eaten somewhere in the bowels of the DigitalOcean App platform. I redeployed a CouchDB Droplet instead of an app and everything works as expected.
This also solved the (not yet tackled) need of storage persistence. An app is epidermal, while a droplet retains data (still need to backup) with attached block storage.
I'm in the midst of testing mod_http_api to replace the existing usage of mod_rest in our implementation.
I can unrestrict access to some commands from group of IP addresses by using option "admin_ip_access". I can successfully execute some commands (e.g. change_password).
However, for some cases, we may require login as well for both user (own)and admin(own and other user).
However, when I tried to login with Basic Auth. It's not successful. I'm keep on getting the following. If my assumption is correct, this might be related to configuration.
Will be much appreciated if someone could show me how the correct configuration should be done.
{
"status": "error",
"code": 31,
"message": "Command need to be run with admin priviledge."
}
Current config
modules:
mod_http_api:
admin_ip_access: admin_ip_access_rule
acl:
admin_ip_acl:
ip:
- "xx.xx.xx.xx/32"
access:
admin_ip_access_rule:
admin_ip_acl:
- all
EDIT
For testing purpose, I've enabled the following configuration:
commands_admin_access: configure
commands:
- add_commands:
- status
- get_roster
- change_password
- register
- unregister
- registered_users
- muc_online_rooms
- oauth_issue_token
I able to run both of user and admin commands successfully for those listed commands inside add_commands tags. It works as expected. However, I still facing some issues, most related to the IP restriction. Calling the API from the host that is not listed in admin_ip_acl also successful where I expect to get error when calling for non-whitelited host
The API requires an OAuth token for authentication. You need to generate one with correct scope. When a command is restricted to an admin, you need to also pass the HTTP header: "X-Admin: true" to let ejabberd know that it should consider you would like to act as an admin.
I have a Icinga2 running with Active Directory as authentication backend and Icinga Web 2 as frontend.
The frontend permissions can be configured using the roles.ini in Icingaweb2's config folder. This is what I have in there:
# roles.ini
[Users]
users = "*"
permissions = "module/monitoring"
As you can see, I want to give all authenticated users access to the monitoring module. I have no group, which contains all users so I cannot use a group for that.
This does not work. How is the correct syntax to give the permission to all users?
(Of course, using existing user names or group names does work, backend configuration therefore is correct.) Thank you very much in advance!
This feature was implemented in IcingaWeb2 version 2.5, see https://github.com/Icinga/icingaweb2/pull/3096. It's a very simple patch against AdmissionLoader.php, which you can also apply separately by hand:
commit f495b390da6eb257ca101889deb70ccc22bb99c7
Author: Eric Lippmann <eric.lippmann#icinga.com>
Date: Thu Nov 16 12:01:06 2017 +0100
Apply role to all users if the role is defined with users=*
If the users directive contains at least one single asterisk, the role is applied to all users.
So, this supports roles which define users=username, ..., * and users=*
refs #3095
diff --git a/library/Icinga/Authentication/AdmissionLoader.php b/library/Icinga/Authentication/AdmissionLoader.php
index 0a80be127..8ee43dbfb 100644
--- a/library/Icinga/Authentication/AdmissionLoader.php
+++ b/library/Icinga/Authentication/AdmissionLoader.php
## -28,6 +28,9 ## class AdmissionLoader
$username = strtolower($username);
if (! empty($section->users)) {
$users = array_map('strtolower', StringHelper::trimSplit($section->users));
+ if (in_array('*', $users)) {
+ return true;
+ }
if (in_array($username, $users)) {
return true;
}
How can I create a system user in Sling?
I tried searching but all I find is related to AEM, which I don't use. Is it possible to create the user using Jackrabbit API or Sling Initial Content (descriptor files)?
I tried to execute the following:
curl -u admin:admin -F:name=myuser -Fpwd=mypwd -FpwdConfirm=mypwd -Frep:principalName=myuser -Fjcr:primaryType=rep:SystemUser http://localhost:8080/home/users/system/*
But there is an error:
*ERROR* [127.0.0.1 [1465215465364] POST /home/users/system/* HTTP/1.1] org.apache.sling.servlets.post.impl.operations.ModifyOperation Exception during response processing.
javax.jcr.nodetype.ConstraintViolationException: Property is protected: rep:principalName = myuser
at org.apache.jackrabbit.oak.jcr.delegate.NodeDelegate.setProperty(NodeDelegate.java:525)
at org.apache.jackrabbit.oak.jcr.session.NodeImpl$35.perform(NodeImpl.java:1358)
at org.apache.jackrabbit.oak.jcr.session.NodeImpl$35.perform(NodeImpl.java:1346)
at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:209)
at org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
at org.apache.jackrabbit.oak.jcr.session.NodeImpl.internalSetProperty(NodeImpl.java:1346)
at org.apache.jackrabbit.oak.jcr.session.NodeImpl.setProperty(NodeImpl.java:432)
at org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.store(SlingPropertyValueHandler.java:592)
There is an out-of-the box solution based on Sling and Jackrabbit Oak. It features a text-based DSL for setting users and ACLs, for instance:
create service user bob,alice
set ACL on /libs,/apps
remove * for alice
allow jcr:read for bob
end
It is also possible to embed these instructions in the provisioning model used to build a Sling launchpad - assuming you're using the slingstart-maven-plugin.
The complete documentation can be found at Repository Initializers and Repository Initialization Language
Not sure this is possible through a post request per: https://mail-archives.apache.org/mod_mbox/sling-users/201512.mbox/%3CCAFMYLMb9Wiy+DYmacc5oT7YRWT1hth8j1XAAo_sKT8uq9HoFNw#mail.gmail.com%3E
The suggested solution is to use the jackrabbit api to do this. This would look something like:
//get a user manager
try {
User systemUser = userManager.createSystemUser("myuser", "/home/users/system");
} catch (Exception e) {
log.error("Error adding user",e);
throw e;
}
//commit changes
It's very important to note that this doesn't allow you to set a password for this user, nor can one be set with user.changePassword() -- when I try that I get an error:
javax.jcr.UnsupportedRepositoryOperationException: system user
From the java doc:
Create a new system user for the specified userID. The new authorizable is required to have the following characteristics:
User.isSystemUser() returns true.
The system user doesn't have a password set and doesn't allow change the password.
http://jackrabbit.apache.org/api/2.10/org/apache/jackrabbit/core/security/user/UserManagerImpl.html
Here's my whole activator class: https://gist.github.com/scrupulo/61b574c9aa1838da37d456012af5dd50