I see an edit variable permission that is scoped to the environment. However, it seems like who ever is responsible for setting up the project, would be responsible for creating the variables, where some other security entity would be responsible for only modifying the values, specifically the secure ones. Is this possible?
Edit:
Adding a little more, I suppose I'm asking for permissions based on the project variable set. Only those with the "EditProjectVariableSet" permission would be able to add or remove variables from the project.
Edit:
Added uservoice:
https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/18022360-separate-permission-for-editing-variable-values-wi
In the Configuration->Teams there is a link to Roles.
You could create a new role, for ex: Variable Editor and only assign VariableEdit, VariableEditUnscoped, VariableView, VariableViewUnscoped.
However I don't think you can restrict to a modification only.
Related
I try to use the PermissionManager (I used UserManager previously). The installation seems to work fine. When I manually add entries to "model_has_permission" and "model_has_role" in the database, the changes are reflected in the UI. But when editing the user I have no options to assign roles and/or permissions like it is visible here:
The installation did not report any errors. What could be wrong or missing?
I've recently updated my serverless project, and I've found that many things have changed in the last few updates.
https://serverless.com/
I don't fully understand whats the correct way to have multiple lambda functions and api gateway endpoints related to the same project. With the old serverless I have every lambda and endpoint as a completely seperate function, this worked pretty well for me.
I can't seem to do this anymore, if I try my second lambda function overrides my first, presumably because my "service name" for both is the same. My service name is the same because I want both rest endpoints in the same API in API Gateway. Since serverless creates the API name based on the service name.
So then I tried to add both functions to the same "Service". this worked for the most part, except that now I need to include my custom role statement for all my functions into the same role (because this one role is now being linked to all my functions). Effectively giving more permissions to each individual function than it should have. The other issue is that all my handler files for the different functions are being put into each functions deployment bundle.
So basically, I'm not sure what is the correct approach to have multiple functions that relate to the same project but are separate in functionality. It used to make sense, now doesn't.
If anybody can give me some pointers please
Thanks
I understand your frustration. I had the same feeling until I looked deeper into the new version and formed a better understanding. One thing to note though, is the new version is not completely finished yet. So if something is completely missing, you can file an issue and have it prioritized before 1.0 is out.
You are supposed to define multiple functions under the same service under the functions: section of serverless.yml. To package these functions individually (exclude code for other functions) you will have to set individually: true under package: section. You can then use include and exclude options at the root level and at the function level as well. There's an upcoming change that will let you use glob syntax in your include and exclude options (example **/*-fn.js). You can find more about packaging here https://www.serverless.com/framework/docs/providers/aws/guide/deploying.
Not sure how to use different roles for different functions under the same service.. How did you do it with 0.5?
I was trying to find a solution for individual iam roles per function as well. I couldn't find a way to do it, but while I was looking through the documentation I found the line: "Support for separate IAM Roles per function is coming soon." on this page, so at least we know they are working on it.
The "IAM Roles Per Function" plugin for Serverless allows you to do exactly what it says on the tin: specify roles for each function. You can still use the provider-level roles as well:
By default, function level iamRoleStatements override the provider level definition. It is also possible to inherit the provider level definition by specifying the option iamRoleStatementsInherit: true
EDIT: You can also apply a predefined AWS role at both the provider and function level.
I have one TeamCity project Dac.Test that contains 3 configurations: DEV, QA, PROD.
Also I have some users associated with their Roles. Is this possible to hide / show certains configurations for selected users or groups?
For example: Users associated with group: Testers can see QA configuration, but not PROD and DEV.
There is no way of managing user permissions per-build, this is available on a project level only. You could create a sub-project in the Dac.Test project to cater for this
If you're looking for a way of stopping people from mistakenly running this build, the following approach will work.
This method uses a prompt box that will pop up after you click the run button, it also needs input from the user confirming that they mean to run the build.
No one can run this build by accident
Go to your build configuration in the TeamCity UI
From here, go to Edit Configuration Settings --> Parameters --> Add new parameter
Enter something like 'Confirmation' as the parameter name
Then beside 'Spec:', click the 'Edit...' button
Set up the parameter as shown in the following screenshot:
You will now be prompted and asked for confirmation when you click the run button. The user will have to enter 'YES' in the prompt box that appears, any other value will stop the user from building:
This is best accomplished by using TeamCity's built-in role management. Roles allow you to set fine-grained permissions for users and groups. One potential issue, however, is that roles are scoped to projects (not build configurations). You'll need to create a separate Dac.Test QA project+configuration and provide your Testers the necessary privileges there. You'll also need to make sure that they are stripped of all privileges for the Dac.Test project.
I'm probably not the first one facing this problem, but I couldn't find a proper answer anywhere.
I have a Windows Forms application that uses a strongly-typed DataSet. The designer uses a connection string defined in the application settings. The trouble is that this setting is defined as Application scope (thus read-only), and I need to be able to change it at runtime. In the settings designer, when the type of a setting is "Connection String", it's not possible to change the scope to "User". And the generated dataset doesn't provide a constructor allowing to choose the connection string at runtime, it always uses the one in the settings.
Do you know why MS introduced this restriction? Do you have any workaround?
I'm currently using a workaround that's really ugly: I change the type of the setting to "String", and the scope to "User". That way, I can change it at runtime and it works fine. The trouble is that when I need to modify the dataset in the designer, I have to change it back to "ConnectionString", otherwise the designer doesn't work.
Thanks in advance for your suggestions!
You can change the value of an ApplicationScope setting at runtime. While the generated and strong-typed property is readonly you can use:
Properties.Settings.Default["App1"] = "bbb";
After that, Properties.Settings.Default.App1 will read "bbb";
This should make it possible to leave the design time setting alone.
You cannot use Settings.Default.Save() for ApplicationScope settings but that is intentional. A normal User does not have the privileges to write in a subfolder of Program Files
What is the difference between the User scope and Application scope in app.config?
User-scope settings are used to store values specific to each individual user, whereas application-scope settings are used for all users.
Take a look at this article.
User Scoped Settings will only affect the current user and are relatively safe to set. They are stored in a user specific location so there is no real issue with writing to them.
Application Scoped Settings on the other hand are read-only and cannot be changed