Good day guy, please i am having issues with my laravel5.5 site online. with this error
domain.com is currently unable to handle this request.
HTTP ERROR 500.
I will appreciate any help or suggestion.
Thanks
Kel
This comes up if you are using Laravel 5.4+ (default database character set changed to utf8mb4) with mySQL version under MySQL v5.7.7.
Edit your AppServiceProvider.php file and inside the boot method set a default string length:
use Illuminate\Support\Facades\Schema;
public function boot()
{
Schema::defaultStringLength(191);
}
After that everything should work as normal.
From: https://laravel-news.com/laravel-5-4-key-too-long-error
Related
I am having a recurring issue with shinyproxy (currently 2.5.0 - based on Springboot) hosted within a kubernetes cluster (currenty a single node). I'm using Auth0 with SAML. Traffic goes through a Nginx ingress controller that does TLS termination and has a fairly basic configuration. What I don't understand is that I will get the following error, but only once in a while. If I try to login, I will get the error, but then after that, if I go back to the login page and try to log in again, everything works fine.
o.s.security.saml.log.SAMLDefaultLogger : AuthNResponse;FAILURE;[Auth0 URN];;;org.opensaml.common.SAMLException: InResponseToField of the Response doesn't correspond to sent message a12g399012cidi7i2i3ha3ha4h6e6jc
at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.processAuthenticationResponse(WebSSOProfileConsumerImpl.java:175)
at org.springframework.security.saml.SAMLAuthenticationProvider.authenticate(SAMLAuthenticationProvider.java:88)
at org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:199)
at org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:219)
...
This made me think of a cookies problem, however adjusting the shinyproxy server/proxy configuration for cookies did not change anything. Shinyproxy configuration has:
server:
secure-cookies: true
proxy:
same-site-cookie: None
In the browser when I try to log in I get the following error message:
Error
Status code: 200
Message: Error validating SAML message
Stack Trace:
org.springframework.security.authentication.AuthenticationServiceException: Error validating SAML message
...
Anyone has an idea of what I am missing? I would really appreciate it! Thank you!
I've been trying to add google login to my django app following this tutorial:
https://github.com/RealmTeam/django-rest-framework-social-oauth2
By following exactly the instructions, everything works fine in local.
However, when I try to replicate the same on the server, I get the following error on the redirect page of the login:
Error 400: redirect_uri_mismatch
redirect_uri: http://localhost:8000/auth/complete/google-oauth2/
What is strange to me is, in my google developer console, I have set up the correct redirect url in my app, as follows:
https://mydjangoapp.com/auth/complete/google-oauth2/
And I have also put 'mydjangoapp.com' under 'Authorised JavaScript origins'.
So my question is, why google keeps telling me that the redirect url is
http://localhost:8000/auth/complete/google-oauth2/
which is not the one I have set up in the console? Perhaps there is something obvious that I'm missing here. Thank you!
Why google keeps telling me that the redirect url is
Because your application is sending its in your code the app is running on http://localhost:8000 and if you are using a client library its probably adding the rest automatically.
http://localhost:8000/auth/complete/google-oauth2/
The redirect uri must exactly match what you are sending from your application.
You need to add
http://localhost:8000/auth/complete/google-oauth2/
Javascript origin is only needed if your code is using javascript.
This video will show you how to fix the error. Google OAuth2: How the fix redirect_uri_mismatch error. Part 2 server sided web applications.
If you want your code to send https://mydjangoapp.com then your going to have to be running it from https://mydjangoapp.com probably and you may need to figure out how to configure it so that it is running from the correct host.
The problem I am facing is that after changing the hostname and configuring the reverse proxy as described here and here, as well as following the troubleshooting guide here to resolve the 'the registered callback does not match' I am unable to get any further.
I've followed a number of other examples of how to configure nginx and add the reverseProxy property to the settings.js configs but with no luck.
As you can see below if I go to https://example.com/publisher I continue getting the error 'The registered callback does not match'
Here is what I have the callback regex set to:
regexp=(https://example.com/publisher/services/auth/callback/login|https://example.com/publisher/services/auth/callback/logout)
If I inspect the authorize request query I can see that the redirect_url is being set to 127.0.0.1 and I suspect that is the problem as when I add that url to the service provider regex callback it works, but this is not suitable in a non local environment.
And here is the request query (where I suspect the main issue lies - note redirect_uri):
https://example.com/oauth2/authorize?response_type=code&client_id=1obvNiUMBcJwMa3euoHjrsckuGIa&scope=apim:api_create%20apim:api_delete%20apim:api_import_export%20apim:api_product_import_export%20apim:api_publish%20apim:api_view%20apim:app_import_export%20apim:client_certificates_add%20apim:client_certificates_update%20apim:client_certificates_view%20apim:document_create%20apim:document_manage%20apim:ep_certificates_add%20apim:ep_certificates_update%20apim:ep_certificates_view%20apim:external_services_discover%20apim:mediation_policy_create%20apim:mediation_policy_manage%20apim:mediation_policy_view%20apim:pub_alert_manage%20apim:publisher_settings%20apim:shared_scope_manage%20apim:subscription_block%20apim:subscription_view%20apim:threat_protection_policy_create%20apim:threat_protection_policy_manage%20openid&state=/&redirect_uri=https://127.0.0.1/publisher/services/auth/callback/login
Here is how my deployment.toml is configured (I've replaced my actual domain with example.com):
Note I had to remove the ports to work behind the proxy
And here is my settings.js:
I added the reverseProxy property as suggested in a github issue
And here is my nginx conf:
This is a known limitation. Please find the steps to resolve the issue - https://apim.docs.wso2.com/en/latest/troubleshooting/troubleshooting-invalid-callback-error/#troubleshooting-registered-callback-does-not-match-with-the-provided-url-error
The reason for this error comes down to a missing X-Forwarded-For header, I ended up changing the forwardedHeader in settings.js to Host as that was being passed from my proxy server.
Thanks for the detailed question "user3745065".
I was having the exactly same issue you described in this post, and I guess I nailed the problem down.
Like you mentioned the issue is with the forwardedHeader, that in your case you switched to Host.
But checking the product documentation, the sample they provide is the following:
customUrl: { // Dynamically set the redirect origin according to the forwardedHeader host|proxyPort combination
enabled: true,
forwardedHeader: 'X-Forwarded-Host',
},
It took me a while to noticed that the forwardedHeader is supposed to be 'X-Forwarded-Host' not 'X-Forwarded-For' as it comes as default.
Few other things I needed to tweak that wasn't clear in the documentation for changing the hostname (here), I had to remove the port variable ${mgt.transport.https.port} from devportal.
That's outlined on the installation step 5 also, here. However worth mentioning:
from:
[apim.devportal]
url = "https://{Your Domain}:${mgt.transport.https.port}/devportal"
to
url = "https://{Your Domain}/devportal"
otherwise when the it tries to redirect to the portal (for instance, from the publisher) it construct the url with the port number, and that default port 9443 isn't going to work on your proxy (tested on nginx with the provided settings that is on the documentation here) which is listening and expecting calls on port 443.
Things that I noticed you configured but perhaps it's not necessary:
Set the apim.idp settings
Set the reverseProxy settings
Set the apim.gateway.environment settings (Not related to the callback url issue, this is meant for you to configure the runtime gateway urls)
Last but not the least, Following the "Troubleshooting 'Registered callback does not match with the provided url' error", again you need to remove the port number from the url, otherwise you will have the same issue aforementioned on your proxy.
Just my 2 cents! ;)
I installed CKAN and I am having difficulty with adding the DataStore extension using as a guide Setting Up the DataStore from the latest CKAN docs. When I get to the line
curl -X GET "http://127.0.0.1:5000/api/3/action/datastore_search?resource_id=_table_metadata", I get this reponse: curl: (7) Failed to connect to 127.0.0.1 port 5000: Connection refused.
When I look at a dataset I created through the CKAN instance through my browser, the data preview on my JSON file shows an error:
Dataset Error Screenshot
and trying to click the upper link to download the file directly also gives me a browser error when it goes to the URL:
Browser Data Download Error
I'm not sure what my next steps should be to figure out what's wrong but I think the FileStore is working since I was able to upload a picture and load it for an Organization listing.
The installation is fresh and has all the default settings from the installation guide so I haven't done any special modifications. Thanks for your help in advance.
Because k-nut's suggestion was the answer but it's in a comment to my question, I thought I'd post an official answer in case anyone else has the same problem. The ckan.site_url needs to be set to the specific URL that CKAN is running under which may not necessarily be a generic one, even if everything else is default configured. In my case, I have a specific internal URL for my VM that I needed to set.
For me ckan.site_url was set to http://demo.ckan.org and http://localhost
took me to the CKAN page as specified in the installation tutorial, then I figured the port used was 8080 and not 5000 by going to http://localhost:8080.
So, I ended up using curl -X GET "http://127.0.0.1:8080/api/3/action/datastore_search?resource_id=_table_metadata" url instead.
I am using jetty version 7.5.1 .
My webservice works fine with a "http://..." endpoint, but when I change it to "https://..." things go wrong.
Endpoint e = Endpoint.create(webservice);
e.publish("https://localhost:" + serverPort + "/ws/mywebservice);
I get the following error message:
"https protocol based address is not supported".
I've tried using an SslChannelConnector, a SelectChannelConnector and the combination of both.
Connector connector = new SelectChannelConnector();
connector.setPort(59180);
SslContextFactory factory = new SslContextFactory();
factory.setKeyStore("keystore");
factory.setKeyStorePassword("password");
factory.setKeyManagerPassword("password");
factory.setTrustStore("keystore");
factory.setTrustStorePassword("password");
SslSelectChannelConnector sslConnector = new SslSelectChannelConnector(factory);
sslConnector.setPort(443);
sslConnector.setMaxIdleTime(30000);
server.setConnectors(new Connector[]{connector, sslConnector});
I also tried modifying the port in the publish path. But without success.
Could it be that something went wrong with the creation of my keystore file?
Even I put the wrong password though, it does show a different error message, explaining that my password is wrong.
My options are running out. Any ideas?
EDIT: More information:
Servlets work fine with HTTPS now. But the webservices are not. Am I maybe publishing it the wrong way ?
I found several threads on various forums with similar problems. But never found a solution. I would like to write down my solution for future victims:
The publish method only accepts the http protocol. Even if you are publishing for https, this should still be "http://...". On the other hand, you should use the port of your SSL connector.
Endpoint e = Endpoint.create(webservice);
e.publish("http://localhost:443/ws/mywebservice);
Use any other protocol and you will always get the "xxx protocol based address is not supported" exception. See source code.
Note 1: The webservice already works fine at this point. However there is a point of discussion: The generated wsdl file (at https://localhost:443/ws/mywebservice?wsdl) will reference the http://... path. You could argue if the wsdl file is a requirement or just documentation.
Correcting a hostname in a WSDL file is not that hard, but replacing the protocol is harder. The easiest solution is probably to just edit the wsdl file and host the file, which is not very "dynamic" of course.
Alternatively, I solved it by creating a WsdlServlet which replaces the address. On the other hand, it does feel bad to create an entire class just to fix 1 character. :)
Note 2: Another bug in this jetty release, is the authentication. It's impossible to offer the webservice without any authentication. The best thing you can get, after turning off all possible authentication: you will still have to use 'preemptive authentication' and enter a random username and password.