So, this happen on my windows 10 machine, CouchDb 3.1.0 and Postman 7.29.1.
During a DB course class i couldn't do the same as my teacher and access:
http://127.0.0.1:5984/_all_dbs
was returning a 401 error:
{
"error": "unauthorized",
"reason": "You are not authorized to access this db."
}
I did some search but couldnt find nothing, than i start to messing things around.
** ATTENTION **
This solution is for local and unsecure enviroment and has by any mean the proposity to solve any other problem.
In the CouchDB/etc, open default.ini, and change the following lines:
; When true, system databases _users and _replicator are created immediately
; on startup if not present.
single_node = true
; prevent non-admins from accessing /_all_dbs
admin_only_all_dbs = false
Than restart Apach CouchDB service (or restart computer). and voila!
Hope that can help others and if my response is duplicated admins feel free to remove it.
Thanks all.
(sry for (m)any spelling/grammatic mistake)
Obs: Another thing that can happen is 401 on new DB. Go to DB permissions and remove _Admin from Members - Roles.
Related
recently in one of my applications I needed to access currently logged-in user data for saving in another model (something like the author of a book or owner of a book). in my googling, I encountered these references but none of them was useful.
https://github.com/strongloop/loopback/issues/1495
https://docs.strongloop.com/display/public/LB/Using+current+context
...
all of them have this problem about accessing context or req object. after three days I decided to switch to afterRemote remote hook and add Owner or Author on that stage.
but something was wrong with this solution.
in strongloop's documentations (https://docs.strongloop.com/display/public/LB/Remote+hooks) there is a variable as ctx.req.accessToken that saves current logged-in user access token. but in the application this variable is undefined.
instead, I found accessToken in ctx.req.query.access_token and it was currently access_token variable that is sent to the server.
here is my problem:
is this variable (ctx.req.query.access_token) always available or
it's just because loopback-explorer send access_token as GET
variable?
in production mode do applications need to send access_token as
GET variable or it should be sent as Authorization in the header?
why ctx.req.accessToken is undefined?
could these things change over time? cause most of users encounter this problem due to deprecation of app.getCurrentContext()
Is this variable (ctx.req.query.access_token) always available or
it's just because loopback-explorer send access_token as GET
variable?
Well if your application always sends in the querystring, then it'll be always available for you, but it also sent in the header, or cookie or in the request body, but I don't suggest using it because it if the user logged in and the access token is valid and ctx.req.accessToken should be available and you can use it.
In production mode do applications need to send access_token as
GET variable or it should be sent as Authorization in the header?
I believe Authorization header is preferred, as if you send it in a GET variable, well it'll be visible in the logs and someone with the access to the logs can access the session(well unless you trust everyone), other than this it's fine to have it in a GET variable. Though I believe loopback client SDKs(Angular, Android, iOS) all send it via Authorization header by default, so you might have to configure them(maybe not possible).
Why ctx.req.accessToken is undefined?
Sometimes the context is lost thanks to the database drivers connection pooling, or the context req is lost(ctx.req) and they are null.
Assuming ctx.req is defined(because sometimes it's not), then probably that means the user is not logged it, or it's access token wasn't valid(expired or not in database). Also it could be a bug(maybe misconfiguration on your side), which also means for you that you will authentication problems.
Could these things change over time? cause most of users encounter this problem due to deprecation of app.getCurrentContext()
app.getCurrentContext is risky to use and I don't suggest unless you have no other solution. If you use it and it works, it might stop working if the database driver changes or in some corner cases that you haven't tested it, it might not work.
In the updated doc https://loopback.io/doc/en/lb3/Using-current-context.html
add this in your remoting metadata
"accepts": [
{"arg": "options", "type": "object", "http": "optionsFromRequest"}
]
then
MyModel.methodName = function(options) {
const token = options && options.accessToken;
const userId = token.userId
}
but it says
In LoopBack 2.x, this feature is disabled by default for compatibility reasons. To enable, add "injectOptionsFromRemoteContext": true to your model JSON file.
so add "injectOptionsFromRemoteContext": true on your model.json file
There are a few topics and articles on Solr authentication & authorization, but I cannot get it to work (the way I like).
I followed these tutorials / information sources:
https://cwiki.apache.org/confluence/display/solr/Authentication+and+Authorization+Plugins
and
https://lucidworks.com/blog/2015/08/17/securing-solr-basic-auth-permission-rules/
Then I created this security.json and I confirmed it is active in Zookeeper:
{
"authentication":{
"class":"solr.BasicAuthPlugin",
"credentials":{
"solr":"...",
"admin":"...",
"monitor":"...",
"data_import":"..."},
"":{"v":8}},
"authorization":{
"class":"solr.RuleBasedAuthorizationPlugin",
"permissions":[
{
"name":"security-edit",
"role":"adminRole"},
{
"name":"security-read",
"role":"adminRole"},
{
"name":"schema-edit",
"role":"adminRole"},
{
"name":"schema-read",
"role":"collectionRole"},
{
"name":"config-edit",
"role":"adminRole"},
{
"name":"config-read",
"role":"collectionRole"},
{
"name":"collection-admin-edit",
"role":"adminRole"},
{
"name":"collection-admin-read",
"role":"collectionRole"},
{
"name":"update",
"role":"dataImportRole"},
{
"name":"read",
"role":"dataImportRole"}],
"user-role":{
"solr":[
"adminRole",
"collectionRole",
"dataImportRole"],
"admin":[
"adminRole",
"collectionRole",
"dataImportRole"],
"monitor":[
"collectionRole",
"dataImportRole"],
"data_import":["dataImportRole"]}}}
I now have a security.json that works for curl requests from command line:
curl "http://localhost:8983/solr/admin/authorization"
Unauthorized request, Response code: 401
curl --user solr:<pwd> "http://localhost:8983/solr/admin/authorization"
Normal response with the info
So far so good.
Now I try and select something from a collection, which shouldn't work anonymously according to my security.json, however it still works
curl "http://localhost:8983/solr/outlets_shard1_replica1/select?q=*%3A*&wt=json&indent=true"
"responseHeader":{
"status":0,
"QTime":1,
"params":{
"indent":"true",
"q":"*:*",
"wt":"json"}},
"response":{"numFound":2000,"start":0,"d.. }
This is the first thing that vexes me. I probably can create some custom path permission for /select, but having the read right assigned to a specific role should do the trick right? but [1] How can I disable all anonymous access?
Continuing on, probably related, it bothers me that the Solr Admin UI(http://solrurl:8983/solr/#) is still accessible. In previous Solr installations (with tomcat) I remember that even this interface was secured. It also seems that I still have complete access to the entire core (reload worked) and I can also inspect cloud configuration.[2] How can I restrict access to Solr Admin UI?
The only stuff that actually seems to be secure is all the /solr/admin related commands
Which brings me to the 3rd thing I can't seem to figure out: How do I configure solr.in.sh so that solr authentication is passed with /bin/solr commands
I see the SOLR_AUTHENTICATION_CLIENT_CONFIGURER and SOLR_AUTHENTICATION_OPTS options, but I have no clue how to modify those to feed basic realm authentication into solr commandline. So [3] How do I keep all access from commandline to Solr (and Zookeeper) authorized & authenticated?
eg. solr status now returns
Found 1 Solr nodes:
Solr process 15931 running on port 8983
ERROR: Failed to get system information from http://localhost:8983/solr due to: org.apache.http.client.ClientProtocolException: Expected JSON response from server but received: <html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<title>Error 401 Unauthorized request, Response code: 401</title>
</head>
<body><h2>HTTP ERROR 401</h2>
<p>Problem accessing /solr/admin/collections. Reason:
<pre> Unauthorized request, Response code: 401</pre></p><hr><i><small>Powered by Jetty://</small></i><hr/>
</body>
</html>
I've tested with
SOLR_AUTHENTICATION_OPTS="-DinternalAuthCredentialsBasicAuthUsername=solr -DinternalAuthCredentialsBasicAuthPassword=<pass>"
To no avail
I also faced the same issue and then I looked at the source code.
The read permission in RuleBasedAuthorizationPlugin is defined as :
read :{" +
path:['/update/*', '/get']}," +
Which will never work.
I have raised an issue:
https://issues.apache.org/jira/browse/SOLR-8439
Now, to lock down your admin ui completely, you need to define a new permission, with path="/", which will going to solve your issue, something like this:
curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 'Content-type:application/json' -d '{
"set-permission" : {"name":"admin-ui",
"path":"/",
"before":"update",
"role":"admin"}}'
Did you forget setting the blockUnknown to true?
Your authentication block in security.json should be:
"authentication":{
"blockUnknown": true,
"class":"solr.BasicAuthPlugin",
"credentials":{"solr":"..."}
},
If you don't set it, it will allow all anonymous access! It is strange but here is the source:
'blockUknown:true' means that unauthenticated requests are not allowed to pass through [1]
Start by using the default user/Pw given in the Solr tutorials.
The passwords are hashed sha512 with a salt. Solr provides the encryption from the plaintext passwords when you create new authenticated users, but the pw in the Lucidworks instructions is already encrypted for the plaintext value: solrRocks (or similar) - use that account to create others, give them appropriate permissions, then remove the solr:solrRocks account.
I accidentaly added admin user in Couch DB and I cant remember password for it. I tried to reinstal CouchDB in local, but admin is still there. Im on mac book.
Is there any way to remove this user?
For server-admins, they are added to your database's local.ini configuration file. Thus, they are accessible via the _config API endpoints:
GET /_config/admins
{
"admin": "<<hashed-password>>"
}
As a result, they can also be deleted via HTTP. (if you're logged in)
DELETE /_config/admins/admin
{
"ok": true
}
Since you specifically mentioned that you forgot the password, you can manually delete the entry in your /etc/couchdb/local.ini file, it'll be listed like:
[admins]
admin=<<hashed-password>>
Simply delete the line starting with admin= and restart your server.
See the docs for more information
I have an interesting issue I've been trying to resolve for a few days.
I'm currently working with an Windows Server 2003 machine that is running a standard instance of Active Directory.
The directory contains two domain components (DCs) that both house users that are going to be authorizing against the directory, via my application.
I'm using :
The IP address of the server as the host name
An SSL connection via port 3269
The GSS Negotiate Auth Mechanism
A BaseDN that is a parentDN of both DC's
The sAMAccountName as the login name
The problem is, I cannot successfully authorize any users from DC1, yet all of the ones who belong to DC2 are completely fine and work great. I get this error on DC1 :
8009030C: LdapErr: DSID-0C09043E, comment: AcceptSecurityContext error, data 0, vece
System.DirectoryServices.Protocols.LdapException: The supplied credential is invalid.
However, using Softerra's LDAP Broswer, I can connect in and authorize the same exact user without any issue, so I know the credentials are correct.
From what I can tell, both of these DC's are configured the same... I've browsed both of them for something, anything that is different... but have found nothing that really stands out.
I posted something months ago about this particular setup, and the code I'm using is in that thread as well.
Set callback for System.DirectoryServices.DirectoryEntry to handle self-signed SSL certificate?
Any help here would be much appreciated.
Thanks!
I was able to get this working, but for the life of me I cannot figure out why this was the case. Basically, this error...
8009030C: LdapErr: DSID-0C09043E, comment: AcceptSecurityContext error, data 0, vece System.DirectoryServices.Protocols.LdapException: The supplied credential is invalid.
...was dead on. The issue was that users logging in under what I called DC2 needed to issue the bind with the domain AND sAMAccountName (Ex. LIB\JSmith), as opposed to DC1, which allowed just the sAMAccountName to be entered.
I figured the best way to make this programmatic was to use the principal binding account to query for the DN of the user. From that DN, using some crafty RegEx, I'm able to capture the domain they inherit from, and issue two separate binds.
SearchResultEntry ResultEntry = userResponse.Entries[0];
//Let's get the root domain of the user now using our DN RegEx and that search result
Regex RegexForBaseDN = new Regex(config.LdapAuth.LdapDnRegex);
Match match = RegexForBaseDN.Match(ResultEntry.DistinguishedName);
string domain = match.Groups[1].Value;
//Try binding the user with their domain\username
try
{
var thisUser = new NetworkCredential{
Domain = domain,
UserName = username,
Password = Pin
};
//If this goes well, we'll continue forward
ldapconn.Bind(thisUser);
}
//If that doesn't work, try biding them with the highest level domain
catch (LdapException ex)
{
if (ex.ErrorCode.Equals(LdapErrorCodes.LDAP_INVALID_CREDENTIALS))
{
var thisUserOnce = new NetworkCredential{
Domain = config.LdapAuth.LdapDomain,
UserName = username,
Password = Pin
};
//If this goes well, we'll continue forward
ldapconn.Bind(thisUserOnce);
}
}
It's not nearly as elegant as I would have wanted, but it does work for this particular scenario.
However, I'm still really interested in why the naming conventions are different depending on which DC the user inherit's from.
We create all our site collections programatically with a custom site def/template. Everything works as expected, except for the crawler. It's apparently denied access to the sites. The crawl logs says:
http://server.localnetwork.lan/somesites/siteName
The object was not found. (The item
was deleted because it was either not
found or the crawler was denied access
to it.)
And in the log files I'm getting this:
08/11/2009 14:20:34.01 OWSTIMER.EXE
(0x0674)
0x1560 Search Server Common
MS Search Administration
7hmh High exception in
SearchUpgradeProvisioner Keyword
Config
System.InvalidOperationException:
jobServerSearchServiceInstance is null
at
Microsoft.Office.Server.Search.Administration.SearchUpgradeProvisioner..ctor(SearchServiceInstance
searchServiceInstance) at
Microsoft.Office.Server.Search.Administration.OSSPrimaryGathererProject.ProvisionContentSources()
If I create a site collection manually the crawler is able to access it. The same users/accounts have the same access on both sites, so that shouldn't be the issue.
The code we use to actually create the site collection looks a little like this:
SPWebApplication app = SPWebApplication.Lookup(new Uri("WebApplicationUrl"));
app.FormDigestSettings.Enabled = false;
app.Sites.Add("url", "title", "description", "language code", "SiteTemplateName", "Owner.Username", "Owner.Fullname", "Owner.Email");
app.FormDigestSettings.Enabled = true;
The code has been slightly altered to protect the innocent... ;)
Any idea what we're doing wrong?
(Please note, I'm not sure if this is a programming error or a config/setup error, so I'm cross-posting with Serverfault)
If you receive this error whilst the crawler account (the default content access account) has read permission to all your sites then you most likely need to disable the loopback check.
http://support.microsoft.com/kb/896861
http://koenvosters.wordpress.com/2009/06/15/access-denied-when-using-hostname-search-and-site-on-moss-2007/