Is it possible to configure default roles for Hasura in config files? - hasura

I'm using hasura via docker. By default there is only admin role and I can add more roles using UI, but after I make restart docker there is only admin again.
Is it possible to setup default user and permissions in config files?

All information about roles is tracked in Hasura's metadata yaml files.
When you add new roles and update the permissions for those roles, you should see that the YAML files are modified to include this information. This is the main way that Hasura allows configuration to be reviewed and managed with version control so that it can be applied safely against different environments.
If you're bringing up the docker containers from scratch (including removing volumes) you may need to run hasura metadata apply against your instance in order for the content of the metadata files to actually be applied.

Related

JFrog artifactory anonymous access is not working

I have free tier account with JFrog. It is working great to hold build artifacts from my Bitbucket pipeline runner.
Now I created a separate artifactory to hold content that I want to provide anonymous access to. What I mean by that is that anyone with link to an artifact can download it without having to login to JFrog space.
I enabled Anonymous access from Admin panels. Then I created a new permission rule for this specific repository; Added anonymous as one of the users with read access.
I tried to access a link under this artifactory. I am being prompted for password.
Wondering what the trick is.

Version maintenance in firebase hosting while using both firebase CLI and REST API for hosting

Our app hosted on firebase hosting is currently updated via firebase CLI. However, our app may get a feature where a user can create some custom static web files and upload a zip file containing those files to our site, after which these files are available as part of the site. (like a wiki/news article). For example: if a user uploads a zip file file which contains an index.html and some images that are linked to the html file, then the site will get updated with these materials and will show them at: oursite.com/username/somearticle/index.html
Through info gathered via this page , it appears that using the Hosting REST API would be able to get the job done. However I have a few questions about the functionality offered by this solution:
To start using the API, we firstly need an access token to authenticate and authorize API requests. Is there a way to get this token for a standard user who's logged in to our site using firebase authentication?
It says in this part of the article that you need the list of all currently existing files and new files in order to update the site. How do I access the list of files that are currently a part of the site?
On a similar note like the above question, we may need to update the app functionality from time to time and those updates are done via the CLI. How do I ensure that these functionality updates don't overwrite updates made by the user? In other words, is there a way to merge updates into the hosting site using CLI commands?
Firebase Authentication users don't have enough privileges to deploy to hosting. The users will need to be collaborators on the Firebase project, which means they'll need to have a Google account.
I recommend checking out my Gist that shows how to deploy a single files, which does something quite similar that what you're trying to accomplish. It gets the list of existing files (and their hashes) in this code fragment.
"When a user uploads a file" doesn't exactly sound alike "version control" to me ...
better use Cloud Source Repositories and add a Build Trigger, which deploys to Firebase Hosting.
Here it's explained: https://cloud.google.com/build/docs/deploying-builds/deploy-firebase
I mean, how else would you'd be able to keep a version history? And if you really want to upload something, just upload, unzip, also commit to git. HTML files are perfectly suitable for that.
The general idea is to have a continuous version history, which automatically deploys itself on change.

What happens if we delete the files from /var/www/html but don't delete the database from mysql

I've inherited a server with Wordpress installed. To uninstall Wordpress steps shared in other queries are that we need to first delete the Wordpress files from /var/www/html and then delete the wordpress database from MySQL.
My question is, what happens if we delete the Wordpress files from /var/www/html but don't delete the Wordpress database from MySQL. Will Wordpress still be present? What can be its impacts?
There are typically three parts to a web application such as Wordpress
The application code
The application instance metadata, stored in a database
The application instance content (data), usually stored in the filesystem
(There are other essential components, such as supporting frameworks, the web server itself, etc., but those are not part of the application so I'm not counting them here.)
If you delete the application but leave the metadata and content, you could in principle reinstall another copy of the application at a later date and reuse the old metadata and content.
The metadata and content are tied together. The metadata describes the content: what it is and where to find it. If you delete either the metadata or the content, the other part becomes useless.
Once you delete both metadata and content, you can reuse the application code to generate a fresh instance of the application.
When you have deleted the application code, the database containing the metadata, and the application content, you should also look to removing the corresponding configuration from your webserver. If this webserver was dedicated to the Wordpress instance it can also be safely removed.

Is it possible to create new custom permissions in wso2 identity server 5.9

Hi I am newbie to Wso2 identity server ,using server version 5.9. I can able to add new users and new roles.Is it possible to add custom permissions that are not in the default list.
There are a few possible ways for you to add custom permissions in the WSO2 identity server.
Method 01:
You can create a service provider and add application-specific permissions to the current registry permission tree. To see how you can do this please refer to [1].
Method 02:
You can add new permissions to the existing permission tree through the registry browse in the Management Console. To see how you can follow this approach please refer to [2].
Method 03:
You can also add custom permissions to the registry through a programmatical approach. To see how you can do this please refer to [3].

Storing configuration settings in web.config or database

What it best location to store various configuration settings of a web site modules.
Creating class (that inherit ConfigurationSection) that map the settings in web.config file?
Or creating some DAL and BLL clases that work with database?
I've used a simple heuristic to categorize each configuration variable into one of four categories:
Compile time configuration (changes done together with code changes) - if possible then inside the code or assembly (as an embedded resource), otherwise in web.config
Server instance specific configuration (SQL connection strings, local file paths) - in web.config
Application (database) configuration (feature selection and other global application settings that change rarely, if ever) - in database but without an UI
Application configuration - in database, accessible through an admin UI
Storing the configuration settings in the Web.config will have the effect that if you modify the web.config file, your application will be restarted and the new settings will have immediate effect.
If you are running the application on multiple machines, you however will need to update each machine.
If you store the configuration settings in the database, you will need to either restart your web application manually or have a function (such as an admin page/site) to allow the application to re-read the settings.
To actually answer the question:
Basic information is going to have to be stored locally in web.config (connection strings etc.)
Beyond that other information could be stored in either location.
Having it in the database means that it's easier to write admin pages to control the information rather than editing the web.config file directly.
How often are things going to change? If set up is a one-off thing then having admin pages would be overkill, but if there's ongoing changes (adding new users, categories etc.) then they might be a good idea.
Also with data in the database you can perform remote administration on the system
So, without more information on your application I can't make a recommendation.
In most times, you have separate settings for each module on each page. Thus, you have to save them in database.
Build a configuration section. It is pretty straight forward and suits your needs.

Resources