I'm developing a VSTS-Extension which will be executable in the contextmenu of a workitem. I need to provide user-level configuration for the action that is performed by the extension (e.g. which external service should be notified, when performing an action). I'll store the data using the Data-Service provided by the API.
Is there a best-practise to make the configuration available to the user (comparable to the configuration of a dashboard-widget)?
There isn’t the configuration view to config context menu of a work item extension.
You can configure it in a backlog tab page and store the settings for the user by using Data Storage.
Related
For securing a frontend application, I created a new Keycloak client with a custom configuration:
mapper which includes "client roles"
scope configuration
client-specific roles (composite and non-composite roles)
This setup works fine in the local development setup. Now we need to transfer this configuration to the other environments like develop/preproduction/production stage.
As far as I understand, Keycloak offers the following exports:
Complete realm
Specific client
It looks as if both apporaches have some major drawbacks. Either I would need to overwrite the complete realm (which I definitely don't want to do in production) or I can import the basic client configuration which is missing all the roles.
And as soon as we, for example, add more roles later on, then we would need to re-configure all stages manually.
Is there some "good practice" how to deal with that? Does keycloak offer some kind of "sync" between stages?
I thought it is hard answer question.
it is compare API call vs UI configuration.
Disadvantage of API call I prefer API call but it takes a time to figure out API function and call order is matter and some properties missing in parent have to set detail in child, complicated structure API URL path ( example id/property/id/property), require more deep of knowledge for Keycloak.
Advantage of API call more fine tunning fast, easy organize from top to bottom (example configure client, Auth resources, auth scopes, policies and permissions to other environment), can transfer 100% configuration.
Disadvantage of UI configuration - not flexible, if un-match, id makes error, can't update/add a partial data (example get client's resource missing it's scopes - it have to set by separate API call), can't move 100% configuration from source to target environment, can make human error
Advantage of UI configuration - easy, quick even manual
My preference is API call - using Postman (single API call or running correction for a sequence of API call - at the local and develop stage, can simple unit test and check HTTP status) and curl call with Bash Schell for higher stage. If check condition of target, can handle scenario based transfer(example already setting, skip that configuration)
One more tips, If using a debug section by F12 in Chrome or Firefox, can see the API call in network tab. It saves time to figure out API call methods and payload/response JSON data.
I am using Grace and I want to configure it to track my settings in appsettins.json file. I can configure that with default container of ASP.NET Core like the following:
services.Configure<DatabaseConnectionSettings>(this.Configuration.GetSection("Database:Connection"));
and later use the IOptions<DatabaseConnectionSettings> or for reloading capability IOptionsSnapshot<DatabaseConnectionSettings> to get the strong-typed values from the container. How can I achieve this when using Grace? and will it support the reload capability of settings when the underlying data changed?
You can continue configuring your application the exact same way. What ever is registered in the service collection will be registered automatically in Grace. I just created an sample app to test that
I am using Wildfly 9.0.2.Final, while in development, all my files that uploaded via my web service and stored in resources/images are gone when I perform a full-publish (luckily this are development dummy images). In production, where is the best place to store or best practice to prevent files/images from missing?
If the files belong somehow to your application, place the somewhere inside the web application (and outside of WEB-INF). They will be accessible through the respective URL path.
If your application needs to store user data that gets uploaded dynamically during application runtime and shall persist even if you redeploy the application, then you better have a configurable directory on disk. One default option to find the JBoss/Wildfly data directory could be to query for the system property 'jboss.server.data.dir'.
Is there a way to configure a container so that for a certain user it allows creation of new objects, but denies deletion and modification of existing objects?
My case is that I provide a web service which receives and serves files using remote openstack swift storage and I want that in case of a credential compromise at the web service level, the person who gains access to those credentials would not be able to alter existing files.
To the best of my knowledge, I don't think it is possible to deny any user from deleting or updating existing objects of the same container, when one can upload objects using credentials.
But you can write a java API and expose it to the user to upload file and internally you can upload the file using the set of credentials. Do not expose the functions that the user is not supposed to do (delete/update etc). You can have all your creds and everything in the code (better to be encrypted). This way you may achieve what you want. But this is a work around.
I have a site that has different features and functionality based on the location that the user has selected. Each location has events that are unique to that location. These events are the primary reason that a user comes to the site for.
There are key areas of the site that are not navigable unless a location is selected for the user. Therefore, the location has to be presumed until the selected location is known -- I plan on using some basic GeoIP lookups for this.
So the requirements basically boil down to:
Location must be set before any page on the site is loaded
User can change the location setting
The location setting must persist from request to request
This setting should be accessible to the layout and view and will be a prerequisite for most controllers
I can think of a few ways off the top of my head to tackle this (Zend_Registry, custom Zend_Session_Namespace, etc) but I'm curious if there isn't a more widely identified strategy for this type of problem.
I see this as similar to setting language for a site with i18n and so i would implement in a similar fashion. Id probably store the location in a session value, or if the user is registered they could obviously save it to their settings/profile in whatever backend storage mechanism is being used. You could also add this location to the route params as is often done with i18n but that could get messy given its a geo location and not just a locale.
I don't think Zend_Registry might fit your needs, since it will only make location settings available throughout the application during a single request but will not persist.
If you need these settings to be persistent between requests, your best (and very likely - only) choice is Zend_Session.
As to #1, I suggest using a controller plugin for that.