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.
Related
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 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.
I am trying to override the connection string in a WCF DataService with CreateDataSource. This seems to work fine for simple requests for tables, but when I try to use a stored procedure it fails...it's always trying to use the original datasource set up for the SP when i worked with the .edmx file.
My code is:
string mConnectionString;
mConnectionString = ConfgurationManager.ConnectionStrings["D7SG_DEVEntities"].ConnectionString;
return new SGEntities(mConnectionString);`
The error which occurs is
The specified named connection is either not found in the
configuration, not intended to be used with the EntityClient provider,
or not valid.
Anyone know how to make this work with a stored procedure ? (This procedure works fine when used with the hard-coded string in web.config)
In your service operation, you're creating the SGEntities without passing in the modified connection string. So it will pick the default connection string from your configuration. In order for this to work you can use this.CurrentDataSource instead of creating a new instance of the SGEntities in your service operation implementation. That will go through the CreateDataSource and should pick up the new connection string.
I'm using EF in my C# project. We're about to add clients which will have other databases with other connection strings.
There's no need to sync between DBs.
I tried using the following c'tor (the 2nd out of 3 supplied):
public AppEntities(string connectionString)
and I get the following error: 'Keyword not supported: 'data source'.'
The connection string is as follows:
metadata=res://EntityFramework/App.csdl|res://EntityFramework/App.ssdl|res://EntityFramework/App.msl;provider=System.Data.SqlClient;provider connection string="Data Source=dbname\dbname;Initial Catalog=App;Persist Security Info=True;User ID=User;Password=password;MultipleActiveResultSets=True"
This is the same connection string that is used when taken from App.Config. I don't want to take it from there but rather build it myself (thus leaving the username & password hard-coded in my app's code and not in free text.
Any idea?
Thanks.
The connectionstring parameter is not an Entity Framework Connectionstring (as in the .config file) but it has to be a "normal" .net connectionstring.
The link's example shows how to "convert" the ef connectionstring to a normal connectionstring (using the EntityConnectionStringBuilder.ToString() method). If you pass the app.config's unprepared string you will get the mentioned error.
You can use the EntityConnectionStringBuilder to parse the app.config value and convert it.
Hope that helps.