i do not know Java and i'm a newbie with CAS. in the CAS documentations there is an example for MongoDb-Authentication(by example i mean a code sample that i should write inside cas.properties), but for Mongo-Service-Management, there is not any example.
MongoDb-Authentication
cas.authn.mongo.collection.name=users
cas.authn.mongo.db.host=mongodb://user:password#ds061954.somewhere.com:61954/database
cas.authn.mongo.attributes=attribute1,attribute2
cas.authn.mongo.username.attribute=username
cas.authn.mongo.password.attribute=password
i did as such and it's working. (i didn't change the third line though, i don't know what it is.)
but in the Mongo-Service-Management documentation
mongodb.host=mongodb database url
mongodb.port=mongodb database port
mongodb.userId=mongodb userid to bind
mongodb.userPassword=mongodb password to bind
cas.service.registry.mongo.db=Collection name to store service definitions
now here we have cas.service.registry.mongo.db so it's probably the name of our db, but they say it's a Collection name. is that a typo?
should the url include the port, the username and password and the name of the database?
the below code is what i did, and it made the /cas path to return 404 Not Found!
mongodb.host=mongodb://myUserName:myPassword#ds061360.mlab.com:61360/mydb
mongodb.port=61360
mongodb.userId=mydb.myUserName
mongodb.userPassword=myPassword
cas.service.registry.mongo.db=services
mongodb.timeout=5000
as i said this make CAS to be unavailable, so i tried changing the url by removing the username and password, or db name, or the port from the url, none of them works.
the _id of the database user in mlab.com is mydb.myUserName, i changed it to myUserName but this didn't help either. can you provide an example or explain what am i doing wrong?
thank you for any help you are able to provide.
Related
I have done everything needed to setup webservices on my moodle 3.11 instance, including roles/capabilities/user. However sending a test request always gives {
"exception": "dml_missing_record_exception",
"errorcode": "invalidrecord",
"message": "Can't find data record in database table external_functions."
}
The URL to access it is of the format https:///moodle/webservice/rest/server.php?wsfunction=core_user_create_user&service=mymoodleusermanage&moodlewsrestformat=json&users[0][username]=ABC&users[0][firstname]=VPTest&users[0][lastname]=None&users[0][email]=mail#xxx.com&users[0][password]=xxxxx&users[0][auth]=manual&wstoken=xxxxxxxxxxxxxx
The service parameter is correctly set to the shortname of the service. Does the service have to be defined anywhere additionally apart from Site Administration->Server->Web Services->External Services->Custom Services
Thanks for any help that can be given
The answer is very simple - you are trying to call a non-existent webservice function (hence the error message about being unable to find the database record for the function in the external_functions database table).
If you look in the Moodle code: https://github.com/moodle/moodle/blob/master/lib/db/services.php#L1717 you will see that the function is called core_user_create_users - with an "s" at the end of it.
If you add that extra "s" into the URL parameters you are using, then it should work.
https:///moodle/webservice/rest/server.php?wsfunction=core_user_create_user&service=mymoodleusermanage&moodlewsrestformat=json&users[0][username]=ABC&users[0][firstname]=VPTest&users[0][lastname]=None&users[0][email]=mail#xxx.com&users[0][password]=xxxxx&users[0][auth]=manual&wstoken=xxxxxxxxxxxxxx
you must change username all character small letter [username]=ABC like this [username]=abc and add s wsfunction=core_user_create_users
I am watching a course about using MongoDB in NodeJS applications, this is one line of its codes:
const url = 'mongodb://localhost:27017/conFusion';
Then it uses it like this:
MongoClient.connect(url).then((db) => {
...
}
I like to know what is the reason it uses the above address instead of the following?
const url = 'localhost:27017/conFusion';
Is there any difference? What is the reason for adding mongodb:// in front of the URL address and what does it do?
"mongodb://localhost:27017/conFusion" points to your local MongoDB database created in MyMongoDB folder. The connect() method returns the database reference if the specified database is already exists, otherwise it creates a new database.
mongodb:// is a required prefix to identify that this is a string in the standard connection format. It is as per the official documentation - Standard Connection String.
Standard connection schema is
mongodb://[username:password#]host1[:port1][,...hostN[:portN]][/[database][?options]]
Hence, you can't use localhost:27017/conFusion as mongodb connection string.
So any one who has used perl dancer knows that to authenticate a user on login you can call authenticate_user
authenticate_user(
params->{username}, params->{password}
);
This is part of the Auth::Extensible plugin.
To me it looks like it encourages the use of storing passwords in plain text! Sure you can hash the password first then make sure the stored password is the same hash but this seems to be more of a work around and i found isn't guaranteed to work. I have only got this to work using sha1 which shouldn't be used. I want to use Bcrypt but the passphrase simply wont match. Possibly odd characters not matching i'm not sure.
The thing is using the dancer Passphrase plugin i can already validate the username and password without even needing to rely on authenticate_user to verify them. But for the dancer framework to consider the user logged in you still have to call authenticate_user which must be passed the password.
I'm completely stuck. I'm curious how other people have managed to use proper password management in dancer2?
Firstly, I'll echo the "you almost certainly don't need to be using authenticate_user()" comments. The plugin can handle all that for you.
However, "it doesn't hash it" is wrong; here's how it works. The
authenticate_user keyword loops through all auth realms configured, and for
each one, asks that provider's authenticate_user() method to see if it accepts
the username and password. The Database provider (and the others) fetch the
record from the DB, and use $self->match_password() (which comes from the
Provider role) to validate it; that code checks if the stored password from
the database starts with {scheme} and if so, uses
Crypt::SaltedHash->validate to validate that the user-supplied password (in
plain text, as it's just come in over the wire) matches the stored, hashed
passsword ($correct in the code below is the stored password):
if ( $correct =~ /^{.+}/ ) {
# Looks like a crypted password starting with the scheme, so try to
# validate it with Crypt::SaltedHash:
return Crypt::SaltedHash->validate( $correct, $given );
}
So, yes, if your stored password in the database is hashed, then it will match
it if the password supplied matches that hash.
For an example of what a stored hashed password should look like, here's
the output of the bundled generate-crypted-password utility:
[davidp#supernova:~]$ generate-crypted-password
Enter plain-text password ?> hunter2
Result: {SSHA}z9llSLkkAXENw8FerEchzRxABeuJ6OPs
See the Crypt::SaltedHash doco for details on which algorhythms are
supported by it, and the format it uses (which "comes from RFC-3112 and
is extended by the use of different digital algorithms").
Do bear in mind that the code behind authenticate_user is exactly what's used
under the hood for you.
For an example of just letting the plugin do the work for you, consider:
get '/secret' => require_login sub {
my $user = logged_in_user();
return "Hi, $user->{username}, let me tell you a secret";
};
... that's it. The require_login means that the plugin will check
if the user is logged in, and if not, redirect them to the login page
to log in. You don't need to call authenticate_user yourself, you
don't need to set any session variables or anything. logged_in_user()
will return a hashref of information about the logged in user (and because
the route code has require_login, there's guaranteed to be one at this
point, so you don't need to check).
If you need to check they have a suitable role, instead of just that they
are logged in, then look at require_role in the documentation instead.
In the documentation for Dancer2::Plugin::Auth::Extensible, the description for authenticate_user() says:
Usually you'll want to let the built-in login handling code deal with authenticating users, but in case you need to do it yourself, this keyword accepts a username and password ...
Which strongly implies to me that you shouldn't be calling this function at all unless you're doing something particularly clever.
I haven't used this module myself, but it seems to me that all the hashing and encryption stuff should be handled by one of the authentication providers and if there's not one that covers the case you use, then you can write one yourself.
Whenever I need to store secure passwords for a Dancer app, I reach for Dancer2::Plugin::Passphrase. I wonder if I should consider writing an Auth::Extensible style authentication provider for it.
I have managed to access a static url but when it comes to accessing an existing collection in mongodb (2.6) through a browser (e.g., http://0.0.0.0:8080/test/test) it returns a 404. Anybody knows if I have to add anything to the default configuration.yml to activate mongo access?
Thanks for help!!
First make sure it is RESTHeart responding you request:
if it is running on your pc, try 127.0.0.1:8080/test/test (not 0.0.0.0)
Also note that in case of 404, you should get a hal+json document with a "message" property (with somenthing like "the db test does bot exist").
If it is restheart, then either the db "test" or the collection "test/test" does not exist an you have to create them first.
If restheart coudn't connect with mongodb you would get "400 Internal Server Error" response code.
Finally I managed to find what the problem was by myself. I post the answer in case it's helpful for somebody else. Thanks Andrea for the help in any case :)
In the static-resources-mounts I had "where: /", which seemed to collide with the mongo-mounts default own "where: /". By changing either where value the access to mongodb retrieves a correct hal+json.
I really appreciate it if you could ask my question.
After I call myObjectContext.myEntitySet.ToList() method in my entity framework context, the password part from connectionstring in myObjectContext.Connection.ConnectionString is gone.is it a bug?
thanks very much for your help.
This is by design. The password is removed to protect you. If you really want to keep the password there you can add the following to your connection string: Persist Security Info=True;
So then your connection string should look something like this:
Data Source=server;Initial Catalog=database;User ID=user;Password=password;Persist Security Info=True;
Be aware that this is a security risk. If your database server supports windows authentication you should use that instead. Then your connection string would be as follows:
Data Source=server;Initial Catalog=database;Integrated Security=True
As you can see this connection string doesn't contain a user name or password. Instead your windows user name and password is used. If you can you should use this instead of the former.