So just recently I started using CloudSQL with an AppEngine instance. I got it working fine. The only thing it did was have one call that stored stuff in a table and one that outputted the content of the table.
All the suddenly when I accesed the page that should output the content of the table it said:
Sorry, unexpected error: (1045, "Access denied for user 'root'#'localhost' (using password: NO)")
I couldn't understand what I did wrong, so what I did was to login, change the password for root#localhost to empty (as it can only be accessed from the GAE anyway) and it started working again, so ofcourse I thought it was my mistake.
The same thing is happening over and over again, makes it impossible to do anything. I set the password for root#localhost to empty, it works, then after a while it stops working.
The AppEngine Instance is in the same project as the CloudSQL DB and I connect to it over a unix socket (using Python, exactly as the example code does). And it works for a while but for some reason stops working after a while.
What am I doing wrong or is it just buggy?
Thanks!
Make sure you run FLUSH PRIVILEGES after you change the password.
Related
im working on a credential provider and got stuck with the following issue:
When the desktop is locked on a terminal server and the password expires, the CP cant seem to change the password.
I can dectect that the password must be changed in ReportResult(), then open a dialog asking for the new password and packing a KERB_CHANGEPASSWORD_REQUEST to hand over in GetSerialization(). This works when the user logs on initially (CPUS_LOGON).
But in CPUS_UNLOCK_WORKSTATION (when the user is already logged in) I get the same ntsStatus (which is 0xC0000224) again in ReportResult() after handing over the KERB_CHANGEPASSWORD_REQUEST
So i wonder if anybody knows what the difference is between those two scenarios - is logonUI expecting a package other than KERB_CHANGEPASSWORD_REQUEST ?
I also tried setting the GetSerializationResponse "status" from CPGSR_RETURN_CREDENTIAL_FINISHED to CPGSR_NO_CREDENTIAL_FINISHED (in the technical reference its said to be the indicator that a password change completed, but thats probably for CPUS_CHANGE_PASSWORD).
The setup im testing this is on is a Win2012 R2 terminal server with a Win2016 DC.
I'd be grateful for any help, thanks!
I have a free heroku plan and a nodejs app on the heroku server. The nodejs app is built with meanjs, so the code for mongodb connections is exactly what you would find in the configuration files. I use a mongolab free mongo database to store the data. Occasionally (depending on how much I interact/change code I believe), the mongodb data is corrupted. I believe this to be true because I use a script to register names, and I can always log into them for awhile until I receive a no user/pass error. If I get this error and immediately create a new user, the user can successfully be logged in and out. All of the user data is still in the database. I also have a few other crud modules that use different collections in the same database, and I (so far) have not seen anything happen to that data, or anything to any of the data besides the password. I don't know where my error is possibly coming from, or what code is relevant, as I haven't touched the config files at all and to my knowledge haven't written any code that looks at user passwords at all. Also, my user object is occasionally empty (user = "") in the markup, but that bug was introduced after the original, I believe while I was trying to find out what was going on. Again, I don't have any clue though, so I included it just in case. Thanks!
After a lot of trial and error, I found the cause to my problem.
After I created these users, I go into my Mongolab account and manually edit the roles based on what module I'm working on (doing role based authentication). It is when editing the data that my passwords become corrupted. I don't know why, but I've pinpointed the problem to there. I've messed with some other data, with similar results.
I am new to gatling and I just want to know if I am doing it right. Here is the scenario.
I am running an application on my local instance, created a simple gatling test to login (with specific credentials), answer a survey(has a specific id) and logout. I have 'testdb' loaded for this app. I run the test, it gives me the result- everything is fine and perfect.
Now I change the testdb to proddb. Note that login creds will be different. so if I run the same test on this new one, I see a few 401 and remotely closed exceptions; but the login part of the test works fine (which as per my understanding should fail- since they are not the old creds). this in the reports shows up as a passed test. How could this happen? Please help. Any explanation as to what is happening and where am I doing wrong will be gladly taken.
Thank you!
I've been struggling to launch a process started under Local System Account (via remote deployment service) under another registered user account. I've followed these steps:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa379608%28v=vs.85%29.aspx
And it works on my local XP-machine. I.e. my process is started from the registered user account and executes everything in the right context. But one of the users (also on XP) has issues, getting error code 5 after CreateProcessAsUser. I cannot reproduce this and am trying to investigate why this is happening.
Interestingly I even removed the permissions to Read/Execute for my registered admin on a specific folder I've got my exe in, but it still runs everything, so I'm not quite sure where to look to find the source of the problem.
I would appreciate any advice in which direction to look in order to resolve this. Maybe you've had similar experience and managed to find a way how to resolve this?
Thanks!
PS I'm simulating local system admin via psexec /si cmd
In the end problem was to do with the local security policy restriction for Local System account + enabling all privileges on the token allowed to start the process.
As for SCCM, once I completely followed MSDN example and interactions were enabled on SCCM-package, things worked fine.
I have a CakePHP website that's been working great.
I just developed a new functionality that at one point auto-logs the user in, and redirects him to a page that's behind the login wall.
This works perfectly well in my dev machine, but in production, the user gets redirected to the login page.
Relevant code: (not much)
$objCustomer = $this->Customer->findById($customerId);
$this->Auth->login($objCustomer);
$this->redirect("/customers/signup");
Customer is the Model that's used for authentication.
In the server, I see that I AM getting redirected to /customers/signup, and that redirects me to /customers/login
The thing that confuses me the most is that this works perfectly in my machine.
I dumped the return value of Auth->Login in the server, and it returns 1, so in theory everything is fine and the user should've been logged in.
Some things I can think of that are different between my machine and the server:
Dev machine is Windows, Server is Linux. This sometimes introduces case-sensitivity issues, but the signup method i'm redirecting to is all lowercase, I don't see where there could be such a problem here.
Dev machine is IIS, Server is LiteSpeed. Maybe Litespeed is screwing with something? This would be the first time in over a year running this site in production that i'd find something different because of LiteSpeed
Production site is over SSL, dev is not. I don't see how this could be a problem.
Any ideas are infinitely welcome!
Thank you!
I had problems too with authentication working fine on my machine in development mode, but not working on the server in production mode. Surprisingly, when I changed the server to development mode it started working correctly. Then I changed back to production, and it was still working. Perhaps it was some cache issue.
After a LOOOONG process of trying different weird things, it turns out it all boils down to this:
ini_set('session.referer_check', $this->host);
That's part of CakePHP's standard security features... It sets that INI setting.
If the request made to the action that'll call Auth->login is coming from another host (domain/subdomain/whatever), PHP will consider the session invalid, which effectively kills the auto-login attempt.