I just remove one user and it appears a ghost user, is it possible to remove ghost user?
I read that a ghost user represents all deleted users. Issues and comments created by any deleted user will be transferred to the ghost user.
But is it not possible to remove it?
I've had a similar problem when playing with gitlab+ldap installation and removing test users, so here is how I removed the Ghost User eventually.
First check whether everything is ok with GitLab (optional step):
sudo gitlab-rake gitlab:check
Execute GitLab console:
sudo gitlab-rails console
Using the console find the the id of the ghost user and delete it:
user = User.find_by(username: "ghost")
User.delete(user.id)
If the user is removed then output would be 1, if 0 then user is not removed.
(...) for future references: API of GitLab doc
User deletion
Deletes a user. Available only for administrators. This is an idempotent function, calling this function for a non-existent user id still returns a status code 200 OK. The JSON response differs if the user was actually deleted or not. In the former the user is returned and in the latter not.
DELETE /users/:id
Parameters:
id (required) - The ID of the user
hard_delete (optional) - If true, contributions that would usually be
moved to the ghost user will be deleted instead, as well as groups
owned solely by this user.
Related
enter image description here After creating the non-admin user I have set permission for a specific database as well but when I log in with a non-admin user its shows a loading database and doesn't show anything and other nodes also don't get loaded.
I found the explanation here
In CouchDB 3.0.0, the /_all_dbs endpoint became admin-only. This has the side-effect of Fauxton, the “Browser GUI”, not loading properly for non-admin users, as it starts out by reading /_all_dbs.
The release notes have a section that go into the changes.
This is the code change: https://github.com/apache/couchdb/issues/2576
You can get the previous behaviour by setting the config variable [chttpd] admin_only_all_dbs to false, but that allows even unauthenticated users to get a full list of your databases.
I am pretty sure my understanding is correct but since I cannot find any Google documentation that explicitly highlights this I wanted to ask here.
Per https://developers.google.com/apps-script/guides/triggers/installable:
Installable triggers always run under the account of the person who created them.
And we know that when you create a trigger it will ask to authorize for all the scopes the script uses.
Then, that means that anyone with edit access to the script could leverage the Google identity of the user used to create the trigger to access the scopes the trigger is authorized for.
For example:
User 1 creates a Google Apps Script that uses GmailApp to send an e-mail
(i.e. GmailApp.sendEmail("one#example.com", "test subject", "email body");)
User 1 creates a trigger to run said script every hour and authorizes it with the appropriate GmailApp scopes
User 1 gives User 2 edit access to said script
Now, User 2 can go into said script and make changes to the code and access User 1's Gmail account. For example, user 2 could change the code to:
var emails = GmailApp.search("search string to find sensitive emails")
// use GmailApp.sendEmail to forward those details to someone else like User 2
All they would have to do is make changes to the code and save; they wouldn't need to re-create the trigger since it already exists. And the next time the trigger runs it would run the newer/updated code.
I was able to confirm this behavior by creating a test script on one of my accounts and giving another account edit access.
So my question is, what is the official/recommended way to mitigate this risk? The obvious answer is to not give anyone else edit access but what if that is not an option -- what if for support purposes multiple people need to be able to access the script, then what?
As you say, the only official/recommend way is to limit editing access to trusted persons.
In your particular example, User 1 could have chosen MailApp instead of GmailApp. The two seemingly redundant services are available separately because MailApp has very limited privledges exposed compared to GmailApp. (For instance, User 2 cannot search the victims Gmail with the MailApp service.)
You can collaborate while avoiding giving direct access to your script file using clasp and git. Only you push with clasp to the script. Everyone else submits changes through git. You can setup the system to be fully automatic (i.e. a git push triggers a clasp push) or manual (i.e. you review all changes first), bit either way you have good records of who did what, when with git.
There's inherent trust when you provide edit access to the script project. You either trust the person or don't trust them. There's no inbetween.
Some "theoretical" ways you may still protect the data:
Create and use different Google accounts.
Install Triggers at the specific deployment/not at Head:
Possible only if done manually. Installable triggers created programmatically can only be used at Head
When you deploy a web-app/api, You can deploy it a specific version.
This deployment version can then be provided, When you create a new trigger for a project here.
There is no need for a working web-app/api. We're only looking to get a deployment id.
In this way, even if user changes the script, your trigger will only run at the old version deployed.
Deployed versions can be seen at Publish> Deploy from manifest.
As the previous answer states, git would be a better call.
For all practical purposes, any data you share with a malicious entity should be considered compromised.
Afternoon all,
I've got an issue when trying to change the status of an order (from pending to complete etc...) in the admin section.
A warning appears saying
Warning: You do not have permission to access the API!
if i have add my IP to the API IP address section it's working fine
the fields are all in red and the continue button doesn't work.
A similar thing happens if I view an order instead and try to add a new status to the order history.
I've seen this problem mentioned a few times in other posts but, afaik, without any satisfactory answer.
I'm using Opencart 2.0.3.1 and I'm logged in as an administrator and the administrator user group has all Access and Modify permissions enabled.
There is the default API user set up in System > Users > API and I also added (and then removed) another one but I was not sure what to do once I had created a new API user with a username and generated password.
There are no other problems on the site but, despite trying just about all the suggestions in the other forum posts, I can't edit the existing orders from the admin section.
Check this page out with a list of fixes for this issue: http://www.randemsystems.com/support/opencart/api-problems-what-you-need-to-know/msg6218/#msg6218
As far as I know, this issue is resolved in OC v2.1x onwards
The problem is that you need an API user with a valid IP address.
Go to System > Users > API.
Either modify the Default API by adding your IP address in the second tab, or just create a new API.
After that you should make sure the API is selected in System > Settings > Edit > Option > API User.
Click save, refresh and try adding order history again.
I tried the same thing and didn’t have permission to access the API when attempting to add order history. Follow the steps and it should work for you, as it worked for me.
I know it's late, but after trying everything and not getting it working, I deleted everything here /system/storage/cache. It solved the problem.
It works perfect for me .
1- Open index.php file of root directory
2- add the following after define('version',x.x.x.x);
if ($_SERVER["HTTP_CF_CONNECTING_IP"])
{
$_SERVER["REMOTE_ADDR"] = $_SERVER["HTTP_CF_CONNECTING_IP"];
}
I'm having issues with the users I've created being able to actually submit anything into the DB I've listed them under. I've followed the steps listed here (Creating regular users in CouchDB) and reviewed countless pages of documentation trying to sort this out. (Ex: http://wiki.apache.org/couchdb/Security_Features_Overview).
I'm using v1.5 and trying to set the user "testAdmin" as the admin for the "test" DB. superadmin, in this is my admin account created through the futon interface.
If I check the security document I can see my permissions there that should allow the testAdmin user to access the DB:
curl -X GET http://superadmin:1234#localhost:5984/test/_security
response:
{
"admins":
{ "names":["testAdmin"],
"roles":[]
},
"readers":
{ "names":["testUser"],
"roles":[]
}
}
Then if I run this, I get "You are not a server admin."
curl -X PUT http://testAdmin:5678#localhost:5984/test/ -d '{"abc": "def"}'
response:
{"error":"unauthorized","reason":"You are not a server admin."}
I've tried switching the user to a reader, I've also tried using the other user I've created that's currently listed as reader, and I keep encountering the same error.
Edit: I'm able to log in to Futon with the users I've created just fine, and their permissions all appear to be working fine within Futon, but I'm still unable to use curl successfully.
You're trying to create a database instead of creating a document. If you want to create document without predefined ID - use POST request instead.
Using
curl
curl -u USER:PASS -X PUT "http://host:port/db_target" -d '{...}'
This may have been the resolution to the initial question.
It's worth adding that Fauxton often "forgets" its authentication if you leave it open and doesn't realize it, failing in odd ways until you reload the page and it realizes you need to log in again.
Short story shorter I was having a similar problem and just needed to re-authenticate to resolve it.
#Kxepal has already solved the problem. So just to make it clear this is what is happening.
You have a superadmin who in couchdb terms is a server admin and can do anything. He/She can create databases, delete them, get any document etc.
Then you have other users who have privileges assigned to them by you. So when you created that _security document what you did was tell couchdb that dbadmin was the administrator of the database and dbreader was a member of the database. From futon this is the definition of admin and members
Database admins can update design documents and edit the admin and member lists.
Database members can access the database. If no members are defined, the database is public.
Once you define an admin or a member your database ceases to be public. Only users with sufficient privileges can access them.
With your request as #Kxepal pointed out you tried to create a database. A database admin can't create a database. That right belongs to the server admin, in your case superadmin.
I have a broken site ATM and the theme layout is stuffed, I need to get to the dashboard by entering the direct link, does anyone have a sample that I can use.
Forced an update of the engine to the lastest version, and found that I needed to make changes to the user roles and configuration, made the changes in the database and got it working. What I found is that the user now needs to be part of a role, in the database made the change to the user giving them role ID of 1, this allowed me to go to the \admin page to get to the dashboard, from there I could reset to a default theme and get the site back up and running again