I used the DCOS 1.8.8，and applied arangodb 3.1.3 on it. When I set the jwt-key and make the authentication works. I meet the following problems.
1.when I open the web site: http://master.mesos/service/arangodb3, I need to fill the user and pasword, however the password for the "root" is not null. I wonder what's the user and password, and how can i get a available one?
2.when I used the coordinator address instand of the master.mesos, and I enter the web UI, then changed the root's password. what's the amazing thing is that the password I set is not work with the web site(used the master.mesos as Web UI).Also the CLUSTER panel doesn't show well（No data~ in total).
Both ArangoDB and DC/OS are using the standard HTTP Authentication header. Under the hood ArangoDB Authentication is working fine however the reverse proxy that DC/OS is using will not forward any authentication down to arangodb. That is why you can't log in into ArangoDB through the DC/OS whereas it will work from inside the mesos cluster.
This is the reason why you have to manually enable authentication via the extra args and there is no simple checkbox for this :( It is simply not supported right now and not really useable.
Related
I am having some trouble and need some help. I am trying to connect a website to authenticate to Active Directory through LDAP using DNN.ActiveDirectory, but I can only get the "Check Root Domain" portion to pass. Using ldp.exe on the server I am able to connect to the domain controller and query the users on it with the same user name and password I am trying to use with the plugin, and even using my domain admin account makes no difference. I have tried it with every authentication type, changing the root domain (only way that would get the check root domain to pass is the LDAP://domain.local), with/without the domain in front of the username, and with/without the default domain filled out.
I don't have access to the error logs at the moment since I am not at that office yet, so I will get those posted when I can. If I remember correctly the error being logged was an authentication error. LDAP initially wasn't configured on the domain controller so I had to set that up, and admittedly I am not too familiar with it so I followed this guide: https://techcommunity.microsoft.com/t5/sql-server-blog/step-by-step-guide-to-setup-ldaps-on-windows-server/ba-p/385362. I am using the default ports. I stopped before setting up LDAPS, but when I couldn't get that to work I continued through up to the signing the certificate part. I was working on getting the certificate signed when I came across notes that DNN.ActiveDirectory doesn't support LDAPS. My tests with successful connections using ldp.exe were all against port 389. Are there some extra configurations that are needed to get DNN.ActiveDirectory working that weren't covered in that guide, or any common snags I should be aware of?
DNN.ActiveDirectory has not been maintained for a while, and does not support LDAPS afaik - see Checking Root Domain step fails.
My recommendation is to have a look at AD-Pro Authentication.
I'm switching over from a heroku addon to a direct redis cloud account and am a bit puzzled on how to generate the redis url with the auth info.
The old heroku add-on url was in the format of redis://rediscloud:mypassword#redis...
However in the dashboard and documentation I don't see any mention of a username to go along with the password. Do I still set rediscloud as the username in my new account and connection string. Does it even matter what I set as the username there?
I use golang (https://github.com/garyburd/redigo) and connect to aliyun cloud Redis (link: https://www.aliyun.com/product/kvstore?spm=5176.8006303.267657.7.cW2xH)
By the connect string:
redis://arbitrary_usrname:password#ipaddress:6379/0
when 0 is the database index and success
At the moment (up to and including v4), Redis doesn't support users and only provides authentication against a global password. In order to be compliant with the URI RFC (https://www.rfc-editor.org/rfc/rfc3986) and based on the provisional RFC for Redis URIs (https://www.iana.org/assignments/uri-schemes/prov/redis), you can pass anything as a username, including the empty string, and it will be okay (i.e. ignored).
P.S. thanks for bringing up this obscurity in our docs, I'll see that it is amended.
Version 6+ now supports users: https://redis.io/topics/acl
If you aren't using an Access Control List (ACL) for your instance (meaning you auth as the default user) or are using an older version of Redis, you should omit the username from your Redis URL (e.g., redis://rediscloud:mypassword#... → redis://:mypassword#...)
If you include a username like rediscloud in the URL and your instance doesn't have that user configured in your ACL, you will likely run into auth issues for WRONGPASSWORD errors as more Redis client libraries implement ACL support.
This format worked for me when SSL is required:
rediss://:password=#redis-server-url:6380/0?ssl_cert_reqs=CERT_REQUIRED'
An example is below:
CELERY_BROKER_URL='rediss://:ahhrk5958rndfngrkqoq=#my-app.redis.cache.windows.net:6380/0?ssl_cert_reqs=CERT_REQUIRED'
CELERY_RESULT_BACKEND='rediss://:ahhrk5958rndfngrkqoq=#my-app.redis.cache.windows.net:6380/1?ssl_cert_reqs=CERT_REQUIRED'
I am trying to connect to a Twitter API endpoint (https) from a Vagrant box (Laravel Homestead), however, I get a 401 authorization required when I try to connect.
On my local machine, everything works well. I am trying to figure out what is different in configuration, but no success. Does it has to do with the OAuth header?
You will need to update your oauth_callback to use your VM's ip instead of "localhost".
A good thing to do might be using this vagrant plugin vagrant-hostsupdater. Then you can set the VM hostname to something like "myproject.dev" and use that as the callback.
I'm trying to use the RavenDB server web/silverlight UI to create databases and test data, and am being asked for a username/password. This is fine, and the documentation on http://blogs.hibernatingrhinos.com/5/ravendb-in-practice-part-1-an-introduction-to-ravendb says that I should use my Windows credentials:
Be default RavenDB allow anonymous access only for read requests (HTTP GET), and since we creating data, we need to specify a username and password. You can control this by changing the AnonymousAccess setting in the server configuration file.
Enter your username and password of your Windows account and a sample data will be generated for you.
However the dialog reappears instantly. A few tries later and it fails with an authorisation error.
I'm using the Raven Silverlight client through Google Chrome Windows XP Home SP3, and haven't changed RavenDB's settings (I want it to work with authentication, rather than dodging the issue).
1) Make sure you give user permissions to read/write in the directory where raven is installed.
2) Make sure that you have set in web.config
3) Check this thread RavenDB Network Access
We are currently facing a production issue on Websphere 7 with respect to richfaces fileupload component. The problem description is that immediately after the file for upload is browsed and selected using this component, the basic authentication dialogbox appears asking for user credentials.
Following are the frameworks we are using in our project:
JSF 1.2 & Richfaces 3.3.3
Spring Framework 3.x
Spring Webflow 2.1
Spring Security 3.x (only basic authentication using login dialogbox)
The user is authenticated once when he wants to access the application at the beginning using basic authentication. All screens that dont use fileupload component are working fine. But if we use fileupload component, as I mentioned above, the file selection (even from local machine path) triggers the basic authentication dialogbox again. The strange thing is that this behaviour does not occur on our Dev Environment which uses Tomcat 6. On Tomcat, the fileupload is not triggering any user login and upload is working fine.
This problem is occuring only when the app. is deployed on Websphere 7. Can anybody please tell whether Websphere requires any additional configuration for accessing Files through this component ?
We have spent a lot of time investigating this problem without any meaningful results. As this is a production issue for us now, it is very critical and needs to be resolved at the earliest.
So please help in this regard. Thanks in advance.
I don't know the File Upload component, and the answer may well lie in the detail of how that works, but in general WebSphere will challenge if an HTTP request arrives for a protected resource and the request does not contain a valid LTPA cookie. The cookie is normally sent by the browser on each request when authentication has happended once, BUT it will only do so if it believes that the cookie is related to a given domain. So if the main part of your website were served from, say,
htpp://my.own.org.com/mysite
and the file upload were related to a subtly different host
http://my.other/filesite
Then the cookie would not be sent, and a challenge would result.
My approach to diagnosing this would be get some kind of traffic sniffer. See exactly what is flowing and the addresses being used. I'm predicting that you will see the LTPA cookie in the usual case and not in the upload case. Then it's a matter of figuring out "why".