I was given a task of fixing an app after the update.
Presumably, the person who updated it said they updated it to 'Oracle 12c' - whatever that means, thought the path is: 'C:/oracle/product/11.2.0/' which sounds like it's still 11.2.0 or whatever.. not important.
Whenever I'm trying to run oci_connect(); with verified and tested credentials, the error pops:
Warning: oci_connect(): ORA-28040: No matching authentication protocol
I've searched around the internet, found 2 solutions:
download and add 'ojdbc8.jar' to 'C:\oracle\product\11.2.0\client_1\jdbc\lib' (hope the path is correct).
add the lines below to 'sqlnet' which I found in:
'C:\oracle\product...\network\admin\' and
'C:\oracle\ora92\newtork\ADMIN'
**I've changed in both to be
sure**.
The lines:
SQLNET.ALLOWED_LOGON_VERSION=8
SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8
SQLNET.ALLOWED_LOGON_VERSION_SERVER=8
Same result, neither worked.
Edit:
I've also noticed, there's no oradmin.exe nor oracle.exe in the bin folder, is this normal?
It sounds like the server is updated and now the client fails to connect. In this case the server needs to configured to allow older client to connect. Add the SQLNET parameters to the server sqlnet.ora file and restart the server.
Related
My dilemma is that I have two domains running on localhost, domain_a and domain_b. They're both running nginx, apache, and php-fpm. domain_a is running CodeIgniter 3.0.0, and domain_b is running CodeIgniter 4. In another VM, I had domain_a in a Docker container, and was able to hit the API endpoints in domain_b without any issues. Development work made it a requirement to have them both be on the same server, as it's close to how it will be in other environments.
For specifics, we're using the PHP oAuth module, and it throws an error that "making the request failed (dunno why)", which is extremely helpful. After some digging, I found that I could hit other endpoints without issue (such as google.com and a known endpoint outside these domains). I attempted to use cURL in place of oAuth (just a simple test to hit the endpoint), and I consistently get the same error.
tls_process_server_certificate:certificate verify failed
The certs I use are all self-signed for both domains, and I'm able to reach both domains from within the browser without issue. If it matters, both domains have user certs when logging in, but the users aren't the same, as each domain has their own self-signed CA.
My current code is this:
$conn = new OAuth($consumer_key, $consumer_secret, $oauth_sig_method);
$conn->enableDebug();
/*
if (is_on_local()) {
$conn->setCAPath('path/to/cert.cert');
}*/
$conn->disableSSLChecks();
$token = $conn->getRequestToken($auth_url);
I left the commented out part in to show what I've tried - I've tried pointing that to the system cert, domain_a CA, and domain_b CA, none of which worked. It looks like (for some reason) $conn->disableSSLChecks() isn't working, but I'm not sure of that. The error thrown is in the call to getRequestToken().
My etc/hosts file:
127.0.0.1 domain_a.tld
127.0.0.1 domain_b.tld
The actual TLD isn't tld, but again, they work in the browser and it worked before when domain_a was in Docker.
I've already tweaked domain_a enough so CI 3 works with PHP 8, so I'm convinced the problem is talking from one domain to the other. I'm running RHEL 8, and I've already got SELinux set to Permissive (actually disabled, I think, for development). There's nothing in httpd, nginx, php-fpm, or firewall logs. The only indicator I have is what I get from CI 3 logs in domain_a:
Severity: Warning --> OAuth::getRequestToken(): SSL operation failed with code 1.
OpenSSL Error messages:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed in /path/to/file
Severity: Warning --> OAuth::getRequestToken(): Failed to enable crypto in /path/to/file
Severity: Warning --> OAuth::getRequestToken(domain_b/oauth/access): Failed to open stream: operation failed in /path/to/file
I feel like the answer is right there, I'm just not seeing it.
As usual, shortly after explaining my issue I found the fix.
Currently, I have the endpoint as https://domain_b.tld/oauth/access. After some tinkering, I got a different error about SSL version. That put me on the track to the correct answer:
http://domain_b.tld:port/oauth/access. I'm able to hit the endpoint now without issue. I've got a virtual hosts file that, even though both domains are on the same port, I had to specify it or the call fails.
If anyone else runs into this issue, check the base URL. I never would have thought about hitting http rather than https as a solution.
I just set up XAMPP and, when I start the Apache localhost, it displays all of these errors when I search "localhost/phpmyadmin"
I am very new to this (just downloaded XAMPP) and I watched this tutorial: https://www.youtube.com/watch?v=hqfIksHKPPg on setting it up (I didn't install phpmyadmin since it was already installed with XAMPP)
I edited the notepad text files as stated in the video, but instead of a login, I get all of the error messages shown in the above picture...
I also opened config.inc.php and edited the line:
['Servers'][$i]['(MySQL root password)'] = '';$cfg
so it matched MySQL root password
Even if you have a suggestion to fix one of the errors, please still comment
Also, if you need any more information please let me know
You're getting several error messages because you have several problems :)
Cannot connect: invalid settings
Some setting is incorrect, most likely something in your config.inc.php is misspelled or incorrectly copied and pasted. Specifically, if the line ['Servers'][$i]['(MySQL root password)'] = '';$cfg is actually how it appears in your configuration, that is clearly the problem as the line should actually be $cfg['Servers'][$i]['password'] = 'green'; except with you password instead of 'green'...except that only applies if your auth_type is 'config', otherwise the 'password' line isn't used at all (since you're prompted for the password at log in). I'm not sure what XAMPP does here for auth_type, but I don't think you should have had to edit the configuration file at all, since you used the XAMPP installer which should have configured everything.
The server requested authentication method unknown to the client [sha256_password]
This appears to be a bit of a version mismatch in your installed files. Access denied after setting user's password with SHA256 in phpMyAdmin goes in to more detail, but this most often occurs when you've got MySQL 8 and PHP older than 7.4. Normally, I'd suggest upgrading your PHP version — but you're using the packaged XAMPP, which certainly wouldn't ship with conflicting MySQL and PHP versions, so something is odd here. Please confirm for us your MySQL and PHP versions. You didn't happen to have an existing MySQL or PHP installation before you installed XAMPP, did you?
Connection for controluser as defined in your configuration failed
This is probably related to the MySQL 8/PHP 7.4 conflict. There is an administrative user (called the controluser) that phpMyAdmin can use to manage some extra features, ordinarily you wouldn't need it to access phpMyAdmin (only to access those additional features), but it seems XAMPP has configured this for you. Since the authentication fails, you get an additional message that the controluser was not able to connect.
You could bypass this by commenting out the configuration lines referencing controluser and controlpass, although again the XAMPP package should have this all configured so I don't recommend that at this point.
The other messages are basically echoes of the previous messages; you get an additional protocol notification because the controluser is trying the same sha256 connection type that the main user was, and then finally phpMyAdmin is telling you that MySQL rejected the connection.
If this is a fresh XAMPP install, I'd suggest reinstalling, because something got a bit confused. I'd also suggest making sure that you don't have any other conflicting software running — XAMPP is a package of all the included parts, so you don't want to install or run your own Apache or MySQL instance which would interfere with the packaged kit.
To compile PHP 7.1.X on Windows I use steps written here:
https://wiki.php.net/internals/windows/stepbystepbuild_sdk_2
When I try to update dependencies with following command:
phpsdk_deps -u
I get following error:
D:\php-sdk2\php-sdk-binary-tools\phpdev\vc14\x64_71_2\php-7.1.15-src
$ phpsdk_deps -u
Fatal error: Uncaught SDK\Exception: Failed to fetch supported
branches
This is happening for almost two weeks now.
You're having network trouble.
If you open up the Config.php file at this line, you'll see that the Config tries to load the URI https://windows.php.net/downloads/php-sdk/deps/series/, and pick the correct txt file from there, in order to download the right dependencies. The exception you get means that this cannot be properly fetched.
The solution in my case was to use the company proxy (command line wasn't using it, so it cannot properly resolve & reach the above URL, and so the Config.php gets an empty response). How to do so might change depending on the network settings you use. In my case, I simply visited the URL above in Firefox (which is properly configured by the company), opened up the network pannel, get the IP of the website from there (which is actually the IP of the proxy Firefox was told to use by the company settings), and add the IP hostname entry in my host file (C:\Windows\System32\Drivers\etc\host) so it looks like 10.1.2.3 windows.php.net
Then I rerun the Config script, and boom, it managed to retrieve the txt files and the dependencies.
Another solution can be to retrieve all the dependencies listed in the txt file that corresponds to your setup, but it's a bit tedious...
So I have a website built in php and it was working perfectly on one server, I then moved the website to a server I have on Digital Ocean and am running into several errors, they seem to be based around http request failures while using the imagick library...
I was hoping to not to have to start debugging this from a code point of view as it was already working perfectly and would prefer to change server settings.
Fatal error: Uncaught exception 'ImagickException' with message 'Imagick::__construct(): HTTP request failed! HTTP/1.1 404 Not Found .
I cannot figure out what differences there, on both server allow_url_fopen is set to on.
The php version is different, 5.520 on the original server, 5.5.9 on the new server.
The versions of imagick are the same. I am also getting some other errors using the mpdf library but I will try deal with these later (Im hoping if I can resolved the first ones these ones will also get resolved).
My question is , is there possibly any other setting on the server I should be looking out for that may be causing these php errors?
EDIT:
Just to add more information, i can get rid of some of the errors by changing the file path https://www.example.com/myimage.jpg to /var/www/example/myimage.jpg . This solves some of the errors but I would rather get the root of the issue thats causing it not to work in the first place, because I feel that its the same problem thats causing other errors.
The error code says it: 404, file not found. You are probably using the wrong URL.
Are you able to fetch https://www.example.com/myimage.jpg using a webbrowser?
On several popular linux distros, /var/www/example/myimage.jpg would be served at https://www.example.com/example/myimage.jpg instead of https://www.example.com/myimage.jpg with the default configuration.
[edit]
It just came to my attention that the URL is HTTPS, there is a possibility that the script is rejecting the server certificate. Try with regular HTTP - no point in using SSL if the file is on the same machine.
I am currently using an image manipulation script to do some work on uploaded images and I'm running into a problem in my dev environment. This same code works on my production server.
The error is:
PHP Warning: imagecreatefromjpeg(): php_network_getaddresses:
getaddrinfo failed: Name or service not known in /path/to/script.php
on line 75
The line of code on 75 is:
$this->img = imagecreatefromjpeg(PHPTHUMB."?src=/".$this->image_path);
which creates an image that is loaded from another made by phpThumb, which is used for further manipulation.
Any ideas on how to solve this? Can anyone shed some light on what the error means?
Thank you,
Edit:
Just as a further bit of insight, if i visit PHPTHUMB . "?src=/" . $this->image_path in my browser, the image loads fine
User agent in php.ini did not solve the problem as indicated here
EDIT (SOLUTION): I had to add the INTERNAL 192.168.204.XXX IP into the hosts file, so that http://dev.mysite.com resolved correctly. Trying both 127.0.0.1 and the external IP yielded no result, but the internal works perfectly. Thanks for everyone's efforts,
I'm totally not sure about the cause of that error, but this is my best guess.
There is a particular PHP Setting which enables you to treat URLs as files. Normally imagecreatefromjpeg accepts a filename, I think. Since you are passing a URL, you need to make sure the particular setting is enabled. I believe you can find more info about it here: http://us2.php.net/file
filename
Path to the file.
Tip
A URL can be used as a filename with this function if the fopen
wrappers have been enabled. See
fopen() for more details on how to
specify the filename and List of
Supported Protocols/Wrappers for a
list of supported URL protocols.
Fopen wrappers: http://us2.php.net/manual/en/filesystem.configuration.php#ini.allow-url-fopen
Your dev environment may not be setup with this, but your production environment could be.
Edit
This page lists your error:
http://bugs.php.net/bug.php?id=11058
and mentions that a possible fix is by modifying your hosts file to explicitly include the ip/dns of the server you're accessing.
i tryed to reconfigure my named
configuration, without any result, to
fix this. the problem was solved by
adding the following line to my
/etc/hosts:
194.97.55.147 mx.freenet.de
Maybe you can try this?
did you also check that allow_url_fopen is set to On in php.ini?
I saw that they did mention that in the article you referred to in your post.
EDIT: Also, what OS and what PHP version are you running?
Just read this on php.net: "On Windows versions prior to PHP 4.3.0, the following functions do not support remote file accessing: include(), include_once(), require(), require_once() and the imagecreatefromXXX functions in the GD Functions extension."
EDIT2:
I just read what was written in the comments, your allow_url_fopen is set to On, sorry about that.
But OS, PHP version and phpinfo() would help in finding the problem.
The error message suggests something is wrong at a networking level. Thus, if possible, bypass that. Try using the path to the thumbnail generator, instead of a network address.
If that's not an option, try something that will give you more granular error messages. I suggest CURL. At the very least, it should yield a more informative error message.
The simple fact that this is failing is because on your webserver, your DNS resolution is broken.
If you have SSH access to your server, try the following command
dig hostname
where hostname is the host name from PHPTHUMB
This will probably fail.
Assuming that you're using Linux, my suggestion would be to edit your /etc/resolv.conf (as root)
and add the following line before any other lines beginning with "nameserver"
nameserver 4.2.2.2
This should hopefully fix things, though you may have to restart apache (or whatever webserver you're using)!
The issue here is that php fails to resolve the url that you provide as PHPTHUMB as stated in this bug report on php.net. This possibly means that it's the fault of the operating system/web server, in which case you can enter the ip address of the server you are connecting to into your hosts file manually.