Am using Jetty 9.2.25 which has Servlet 3.1. I have below cookie configuration in my web.xml
<session-config>
<cookie-config>
<http-only>true</http-only>
<secure>false</secure>
</cookie-config>
</session-config>
When I set this secure flag as true, it's working. But when I set it as false as shown above and access https site, the secure flag is getting modified to true and I am not able to access http site. I don't understand how is this happening?
Is this the default behaviour?
I tried to check the Servlet release notes, but there's no such update.
Any idea regarding this behaviour?
How can I make the secure as false when I access https?
Thanks in advance.
Jetty 9.2.x is EOL (End of Life).
In Jetty 9.4.x (current supported / stable releases of Jetty), you would configure your SessionHandler to not have secure requests on by default to achieve the behavior you want.
SessionHandler.setSecureRequestOnly(false);
Note: this feature is not available in Jetty 9.2.x
Related
I have an ASP.NET webforms/mvc hybrid app deployed on IIS 10. I have two bindings for this app one with just a localhost:portNo binding and another with DNSDomainName:portNo binding. Both are Http bindings. SSL is turned off. I get the error
"This attempt to set a cookie via a Set-Cookie was blocked because it had the "Secure" attribute but was not received over a secure connection."
when I test the DNSDomainName:portNo binding (it is failing to set sessions). The localhost:portNo binding works without any issues. Why is this happening? and how do I fix this?
Your cookies are configured to require an HTTPS connection. When you try to set them on a non-secure connection, they will be rejected.
Check your web.config file settings for:
<httpCookies requireSSL="true" />
Change that setting to false, and your session cookies should start working.
NB: Once you publish your site, it should only ever be served over HTTPS, and this setting should be changed back to true.
Secure Cookie Attribute | OWASP Foundation
The localhost binding works because most browsers have special-case code to treat connections to that host name as "secure", even if they don't use HTTPS.
Locally-delivered resources such as those with http://127.0.0.1 URLs,
http://localhost and http://*.localhost URLs (e.g.
http://dev.whatever.localhost/), and file:// URLs are also considered
to have been delivered securely.
Secure contexts - Web security | MDN
I'm using cloudfront on lightsail on my website https://topshelfaquatics.com with the help of W3Total Cache. I've used all the possible ways like allowing headers (Origin) in Cloudfront but still it is not solving.
Can you suggest me a solution?
Please look at your network tab in the developer tools. This will give you information about the http calls. Most of the time the browser give this error when it's a xhr (ajax) call and no Access-Control-* headers has been set in the response. In order to solve this there are two possibilities:
Do not use xhr requests for fonts, so do not load fonts from JS. Use the default methods in html/css for loading fonts.
Add the required Access-Control-* headers to the http response. This requires involvement of cloudfont.net, so this solution might not be very realistic.
Cross-Origin Resource Sharing - CORS - is a mechanism that use some additional HTTP headers to inform the browser that access resource has different domain from origin.
You try access resource at Cloud Front, without setup the allowed domains int, below a example that enable CORS, for HTTP method GET and all headers, in Cloud Front:
<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
<AllowedOrigin>https://topshelfaquatics.com</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
<MaxAgeSeconds>1800</MaxAgeSeconds>
<AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>
Cross-origin resource sharing (CORS) is a mechanism that allows restricted resources on a web page to be requested from another domain outside the domain from which the first resource was served. ... Certain "cross-domain" requests, notably Ajax requests, are forbidden by default by the same-origin security policy.
Chrome browser install Extension:
https://chrome.google.com/webstore/detail/allow-cors-access-control/lhobafahddgcelffkeicbaginigeejlf?hl=en
As default Config during WSO IDentity Server (WSO2 IS). we can access to admin by the https request with the port 9443 with the below link:
https://localhost:9443/carbon/
But as mentioned on the below link.we can access through Http request with port 9763. But when we access with the http request, It will redirect automatically to https.
https://docs.wso2.com/display/IS500/Default+Ports+of+WSO2+Products
I also tried to find and see a confit relating to http and https in IS_HOME/responsitory/conf/axis2.xml.
<transportReceiver name="https"
class="org.wso2.carbon.core.transports.http.HttpsTransportListener">
<parameter name="port">9443</parameter>
</transportReceiver>
<transportReceiver name="http"
class="org.wso2.carbon.core.transports.http.HttpTransportListener">
<parameter name="port">9763</parameter>
</transportReceiver>
I tried to comment a config relating to https and build again but the result is not good when I had exception here.
I want to ask how to config in WSO2 IS to use HTTP as default to access instead of HTTPS as the initial config.
I would be happy if y can support me in this case.
Thanks.
In recent versions of WSO2 IS, follow the below steps to enable HTTP access to management console.
Go to the $IS_HOME/repository/conf and open carbon.xml, and uncomment
<EnableHTTPAdminConsole>true</EnableHTTPAdminConsole>
Disable secure cookie parameter in $IS_HOME/repository/conf/tomcat/carbon/WEB-INF/web.xml file.
<session-config>
<cookie-config>
<secure>false</secure>
</cookie-config>
</session-config>
To enable HTTP access to management console Open carbon.xml located at WSO2_HOME/repository/conf directory and uncomment the following line.
<EnableHTTPAdminConsole>true</EnableHTTPAdminConsole>
Now you should be able to login. See the following.
I moved from IIS 6 on windows server 2003.
I can browse to the .svc files. I get a nice standard "This is a Windows© Communication Foundation service" page if I go to http://example.com/Service.svc in a browser.
But I can't browse to any of the methods - I get a 404 error if I go to http://example.com/Service.svc/Method?parameter=xyz in a browser.
Has anyone seen anything like this? Any ideas or suggestions?
I thought I might have a similar problem to this question: WCF on IIS8; *.svc handler mapping doesn't work
But the symptoms are different (looks like they can't see .svc files at all) and none of the solutions work (I have Http Activation for WCF features installed, etc).
OK, I gave up and paid Microsoft $250 for support. With the tech's help, we found the solution, and last night confirmed that it was definitely the solution for all our servers: We disabled SSL altogether for WCF services in the web.config:
<system.serviceModel>
<bindings>
<webHttpBinding>
<binding>
<security mode="Transport" />
The "Transport" refers to Transport Layer Security (TLS is the new SSL) so HTTPS. Changed that to:
<system.serviceModel>
<bindings>
<webHttpBinding>
<binding>
<security mode="None" />
Turns out WCF is extremely sensitive to whether you are using HTTP or HTTPS, and if you are using the wrong one you get no helpful errors, just 404.
In my case, both old and new servers were configured to use HTTPS at all times for security. But on the new servers, the SSL (TLS) encryption terminated on the load balancer. In that case encryption only happened between the user's browser and our load balancer, and the traffic between our load balancer and the web servers was unencrypted HTTP.
So the service was listening on HTTPS, and when the request came on HTTP, it just completely ignored it.
(All the other talk about similar issues online focused on uninstalling and reinstalling IIS and ASP.NET and WCF and HTTP Activation and such, so I hope this helps someone. I recommend MS Support if you have a question on the MS stack that SO can't answer in time. It was certainly much cheaper than wasting a few more hours trying to fix it alone).
Please check if your IIS has svc handler added.
WCF services don’t run on IIS 8 with the default configuration, because the webserver doesn’t know, how to handle incoming requests targeting .svc files. You can teach it in two steps:
Add a new MIME type:
Extension: .svc
MIME type: application/octet-stream
Add a new Managed HTTP Handler:
Request path: *.svc
Type: System.ServiceModel.Activation.HttpHandler
Name: svc-Integrated
Refresh your website/web application
References:
http://gyorgybalassy.wordpress.com/2012/09/24/publishing-a-wcf-service-on-iis8/
http://proq.blogspot.hk/2012/09/wcf-on-iis-and-windows-8.html
http://forums.iis.net/t/1200413.aspx?+svc+missing+can+t+find+Module+to+load+within+Handler+Mapping+IIS+8+0
Just wanted to provide a collection of suggestions in case you haven't tried one of these:
Any chance the [OperationContract] is missing for the intended method?
Do you have any url rewrites configured in the web.config that could be redirecting the method calls, such as an HTTP/S redirect or some route configuration?
Enable Failed Request Tracking in your IIS to see what sub-type of 404 error you are getting? 404.13? something else? It is likely not because something isn't found, but some other error in the request.
Additional Sources:
http://www.iis.net/learn/troubleshoot/using-failed-request-tracing/troubleshooting-failed-requests-using-tracing-in-iis
WCF service returning 404 on method reqests
https://social.msdn.microsoft.com/Forums/vstudio/en-US/7d69a209-489e-486c-81f4-a660c539ae49/wcfiis-7-returns-404-but-only-for-some-method-arguments?forum=wcf
https://social.msdn.microsoft.com/Forums/vstudio/en-US/7d69a209-489e-486c-81f4-a660c539ae49/wcfiis-7-returns-404-but-only-for-some-method-arguments?forum=wcf
You can enable tracing/logging in wcf service , so that you can check actual cause of error, if there is mismatch in param or any other thing , directly from error logs.
Refer this to enable tracing, it is just simple config setup - http://msdn.microsoft.com/en-us/library/ms733025(v=vs.110).aspx or How to turn on WCF tracing?
...
Other suggestions:
In ServiceContract, for required method, you have used required attributes. So lets say, Service.svc has servicecontractor defined in IService.cs, and you are concerned about Method. Then Method should be declared like this.
[OperationContract]
[WebGet(UriTemplate = "Method?parameter={value}")]
string AnyMethodName(string value);
Here i have used string as both input and output param type, you can use required type here.
Apart from this, you need to have required web.config to have service,binding,endpoint etc. configured properly. Refer - http://msdn.microsoft.com/en-us/library/ms733932(v=vs.110).aspx
So that if you host it in http://www.example.com, then you can execute REST based Get request using http://www.example.com/Service.svc/Method?parameter=XYZ.
More info - http://www.c-sharpcorner.com/UploadFile/b1df45/rest-based-api-using-wcf-services/
Also, as suggested above, there might be some URL rewriting setup, that you have check and fix. or try with https version of URL directly. Or if there is some proxy server that is blocking, has to be checked.
If there is request filtering setup, then check if GET request is blocked there.
Or if at all possible, re-register IIS using aspnet_regiis.exe -iru.
Hope it will help to somebody though its late to reply to this post.
I got the same problem and spent hours and hours to find the solution. Finally ended up changing
Luckily I got the answer changing RouteConfig.Cs file as follows From
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
To
routes.IgnoreRoute("{resource}.svc/{*pathInfo}");
as long as you should place your .svc file in root of your application.
That was my own question asked on this link
WCF Service throws Http404 on any request except .svc
We have Jira 5.x running in the standalone variant (embedded tomcat). We'd like to prevent any request without a valid http basic header from reaching the Jira application. Or, in other words, force JIRA to use HTTP Basic authentication. Yes, I know that transmitting http basic credentials over the wire without tls isn't secure and stuff, but we don't have an SSL certificate anyway, so that doesn't matter (it doesn't make it worse than it actually is).
I read that Jira handles HTTP Basic Authentication headers if it gets them, and appending ?os_authType=basic to the URL makes Jira behave as we wish, but we'd like Jira to enforce HTTP Basic. We wouldn't care if we had some kind of "even-before-jira" login statically configured in tomcat as long as the jira application wouldn't be reachable from outside without it.
Is there a way to achieve this?
I tried adding:
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
to jira's web.xml but that didn't help.