I am using PowerBuilder PFC library to login to the database.
n_cst_appmanager/ pfc_open:
IF this.of_LogonDlg() > 0 THEN
Open(w_myapp_frame)
END IF
n_cst_appmanager/ pfc_logon:
SQLCA.DBMS = "ODBC"
SQLCA.AutoCommit = False
SQLCA.DBParm = "ConnectString='DSN=mytestdb;UID=" + as_userid + ";PWD=" + as_password + "'"
connect using SQLCA;
Now, once the user is logged in, there are few situations that I will need to connect to another database (for example, to copy some data there), so I would like to connect to the other database automatically, without displaying the login window again, therefore I would need to save the username and password of the user.
How can I save it? Do I need to save in the registry? Can you give some example please?
For example, I can get the user id in following way:
s_userid = gnv_app.of_GetUserID()
But I can not get the password. Can someone please help me how i can do it? Thanks a lot.
Actually, now that I'm paying attention to what you need instead of what you asked for <g>, and riffing off of Hugh's answer, why not just copy the transaction object?
n_cst_String lnv_String
ltr_NewConnect.DBMS = SQLCA.DBMS
ltr_NewConnect.AutoCommit = SQLCA.AutoCommit
ltr_NewConnect.DBParm = lnv_String.of_GlobalReplace (SQLCA.DBParm, "mytestdb", "myotherdb")
If I were doing this, I'd code a copy of all the transaction object fields, just in case the means of defining the connection changes.
I'm assuming the other database is the same type of database in order for this to make sense (so that it uses the same type of DBParm), but either way the principle may apply.
Good luck,
Terry.
There's nothing built into PFC and there's nothing automagic in PowerBuilder that will help you with this. Just create an instance variable and a function to access it. Maybe grab the n_cst_LogonAttrib from the Message.PowerObjectParm immediately after the call to of_LogonDlg() and grab the value from there. Or, further extend your n_cst_AppManager.pfc_Logon event. Or extend of_LogonDlg(), and model the capture after the way PFC does the user id.
Note that storing the password anywhere permanent and visible to other processes like the registry would be a security violation that many companies would not allow. Not a direction you want to go.
Good luck,
Terry.
You can parse them out of SQLCA.DBParm.
string ls_userID, ls_password
n_cst_string stringSrv
ls_userID = stringSrv.of_getKeyValue(SQLCA.DBParm, "UID", ";")
ls_password = stringSrv.of_getKeyValue(SQLCA.DBParm, "PWD", ";")
However, a good case can be made for capturing them in the appmanager if you know you will need them.
Having the same login credentials for different databases is a security concern. It's the sort of thing that leads to your company being in the news for the wrong reasons.
Related
We're moving and updating our database because it's due for it, but we have an issue concerning authentication. We'd like to connect to the database only with an authentication key.
Our old CouchDB were not using any user and all the databases were public (no users permissions or anything like it). It was working but it is not what we want.
Now, with our 'new' CouchDB, we'd like to have our connections made with an authentication key only, but it looks like there's an expiration on the sessions made and we can't find the way to have a token permanent.
For the context, I'm using couchdb-python for my tools and I found some ways to start a session and get the cookies, therefore the authentication key, but either it is via couchdb-python or the web platform (Fauxton I think it's called), the expiration time is still there and after the timeout (as shown below) the session does expire.
Below is our local.ini for it.
We tried to add both required_valid_user = false and allow_persistent_cookies = true but to no avail.
[couchdb]
uuid = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
[couch_peruser]
[chttpd]
port = 5984
bind_address = 192.168.140.66
require_valid_user = false
[httpd]
[couch_httpd_auth]
require_valid_user = false
secret = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
allow_persistent_cookies = true
timeout = 600
[ssl]
[vhosts]
[admins]
admin = -xxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx,xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx,xx
I'm pretty sure there's something we're overlooking or that we did not understand correctly.
Is there a way to get an authentication key to be permanent?
Is there a way to get an authentication key to be permanent?
The best would just be to use password authentication. The password never changes (unless you change it, of course).
But if you insist on using a token, you can increase the session timeout to some insane value:
[couch_httpd_auth]
timeout = 99999999999999
This is untested. I don't know what the maximum value is.
I am writing a WordPress plugin.
In one program, I capture the WordPress user id and write it to a file in a custom database.
Another program connects to the custom database, retrieves multiple rows having the user id:
$connection = new PDO("mysql:host=$dbhost;dbname=$dbname", $dbuser, $dbpass);
$sql = "SELECT ...";
$prep = $connection->prepare($sql);
and tries to access the wordpress function after retrieving each record:
$user_info = get_userdata($user_id);
As soon as the get_userdata function is executed, the programs dies.
Do I need to connect to the wordpress database?
If so, how?
First of all, Why you have made database connection manually this way as you can able to use global variable "global $wpdb;" and then able to write query based on "$wpdb".
Second thing, you might declare that $user_id variable as global, so can access it globally in file or you should define in functions.php file and check for their availability.
Please let me know if any of this solution does not work for you with details.
I am trying to connect to D3 Database with MVSP java api. So far:
I have downloaded the mvapi.jar
added it in project lib folder
written the sample code for connection inside main method
String url = "jdbc:mv:d3:hostname:portNo";
Properties props = new Properties();
props.setProperty("username", "");
props.setProperty("password", "");
String account = "AGCO";
String password = "";
MVConnection connection = null;
try {
// Getting error at this point
connection = new MVConnection(url,props);
MVStatement mvStatement = connection.createStatement();
connection.logTo(account,password);
MVResultSet results = mvStatement.executeQuery(query);
}
com.tigr.mvapi.exceptions.MVException: server error with errorCode 1023.
I checked the console but I'm not able to figure out the actual cause or whether I am entering the wrong username, password.
Please suggest what I am doing wrong.
First, you have to set a breakpoint or trace which function is throwing the errors. Then check the routes, (FileName) probably you will have much more experience than I do, but keep in mind that giving the full route ("account,filename," where the last comma is important) is never a bad idea while keep you safer and is mandatory if the filename is in a different account that you are logged to.
And like always please verify these things:
You have enough licenses. Try to close any terminal you have opened for testing your queries. Yes you know is true. One connection one license. Sometimes MVSP let you two under the same IP but chek this.
MVSP service is running. See Pick D3 documentation.
Your USER and ACCOUNT are both ENABLED to access in the MVSP server otherwise you won't be able to access these files or login with the user through the API. See the documentation to enable in the MVSP.Menu account.
I hope this helps.
I've read questions on Stack Overflow very similar to this question, but not quite the same.
Let's say that I had the following config.inc.php file included on every page of my website:
<?php
$site_name = 'Acme Inc.';
$authenticate_with_ldap = true;
$ldap_host = 'ldap.example.com';
$ldap_port = 389;
$ldap_rdn = 'ldap-user';
$ldap_password = 'ldap-pass';
$ldap_dn = 'ou=example,dc=example,dc=com';
$smtp_username = 'smtp-user';
$smtp_password = 'smtp-pass';
$recaptcha_publickey = 'my-recaptcha-publickey';
$recaptcha_privatekey = 'my-recaptcha-privatekey';
?>
Note: I have chosen to keep the website configuration in a file instead of the database because the information is used all over the website and it would be a lot more code and, I'm guessing, a lot more overhead to have to query the database for the same information all the time.
Now let's say that the website administrator is the type of person who would prefer to edit the above information using a CMS as opposed to going in and editing the file manually. My fear is that when the website administrator clicks the "Update" button and the PHP script gets to the file_put_contents function that overwrites the config.inc.php file, something could go wrong and either corrupt the file or make it unusable due to a syntax error or something.
Is this a reasonable concern? Should I tell the website administrator that he should just tough it out and edit the file manually? Should I store the information in the database instead? Or should I store the information in both places so that if the file gets messed up, it can be regenerated using the information in the database?
If you store that info in the DB as a single row of data, wouldn't it be cached anyway?
I'm trying to authenticate against the user db of my website (CMS based) and it uses a slightly different approach at storing hashed passwords. It uses a randomly generated salt for each user. The salt is stored in the user db along with the hashed passwords. Hence, direct field-mapped authentication (as the External DB plugin does) won't work for me.
To start off, I just mirrored the DB plugin and modified the user_login() procedure to read the hashed password and the salt from the database and then hash the entered password again with the salt and match it up with the password in the database. Here's the code for my user_login() function
function user_login($username, $password) {
global $CFG;
$textlib = textlib_get_instance();
$extusername = $textlib->convert(stripslashes($username), 'utf-8', $this->config->extencoding);
$extpassword = $textlib->convert(stripslashes($password), 'utf-8', $this->config->extencoding);
$authdb = $this->db_init();
// normal case: use external db for passwords
// Get user data
$sql = "SELECT
*
FROM {$this->config->table}
WHERE {$this->config->fielduser} = '".$this->ext_addslashes($extusername)."' ";
$authdb->SetFetchMode(ADODB_FETCH_ASSOC);
// No DB Connection
if ( !$rs = $authdb->Execute( $sql ) ) {
$authdb->Close();
print_error('auth_dbcantconnect','auth');
return false;
}
// No records returned
if( $rs->EOF ) {
$rs->Close();
$authdb->Close();
return false;
}
// Get password
$db_password = $rs->fields['user_password'];
$salt = $rs->fields['user_salt'];
// Close DB Conn
$rs->Close();
$authdb->Close();
// Return match
return sha1( $extpassword . $salt ) == $db_password;
}
But when I try to login, username / passwords corresponding to the website (CMS) database are failing. However, the password (for the same user) that was stored in Moodle earlier on (before I tried using this custom plugin) is getting me through.
That means, either my authentication routine is failing or moodle's internal db based auth mechanism is taking precedence over it.
I've enabled ADODB debug mode - but that isn't helping either. When I enable the debug output from Server settings, the error messages are being sent prior to the page headers. Thus the login page won't display at all.
I have all other forms of authentication turned off (except for Manual which can't be turned off) and my own.
Any ideas on how to solve this issue?
Can you confirm the order that the authentication pluggins are displayed? This will determine the order in which they are used. See..
http://docs.moodle.org/en/Manage_authentication
Either way, the behaviour you're seeing suggests that your code is returning false and the fall through logic described here...
http://moodle.org/mod/forum/discuss.php?d=102070
... and here...
http://docs.moodle.org/en/Development:Authentication_plugins
... is kicking in.
Have you tried returning "true" always from your plugin to ensure that it's being called. Then, you can start returning "true" based upon other things (hard coded usernames etc). This approach will allow you to get to the point where you are either continuing to fail or seeing more targetted failures. Are you sure, for example, that it's the user_login function and not the subsequent call to update_user_record that is failing?
Finally, are you sure you're generating the salted password in the exact same way that it was created in the first place? This would be, for me, the most likely cause of the problem. Can you take control of the creation of the salted password so that you own both creation of new users and authentication of users - this would ensure that you were in sync with how the salted password and hash were generated.