When configuring ServiceStack, I have to specify a location (URL) at which my services will be available. E.g. when running side-by-side with WebApi:
<location path="svc">
<system.web>
<httpHandlers>
<add path="*" type="ServiceStack..." verb="*"/>
</httpHandlers>
</system.web>
Now all my ServiceStack-based services will be available at http://server/webapp/svc/{route}.
After reading the page about modularizing services into plugins, I was wondering: is it possible to register the service(s) contained in each plugin at a different URL (e.g. vary the /svc/ segment of the URL per plugin)?
See the configuring ServiceStack section in Hello World example on how to register ServiceStack to run at a custom path.
You will also want to read the README section and answer if you're trying to run ServiceStack with MVC.
(in response to the comment)
There's only 1 ServiceStack AppHost in every host application, which can only be hosted on 1 root / or /custompath. All other route configurations are mapped from that /path. So if you register it at /svc you can't register a new ServiceStack AppHost from a different mount point e.g. /svc2. If you hosted it at root path / then your individual routes can be hosted at /svc/route1, /svc/route2, etc. But then you wont be able to host it side-by-side with another web fx (e.g. MVC or WebAPI).
Related
I'm deploying using VS2017, and MSdeploy WMSVC seems to be overwriting my IIS site settings being deployed to.
The site settings, in IIS manager, has IIS Authentication panel, Anonymous Authentication Credentials set as Application Pool Identity.
After deployment, all requests get 401.3 unauthorized error, because the Anonymous Authentication Credentials setting gets set to user:
Clearly this is getting overwritten because of a clash between SERVER specific settings and DEVELOPMENT specific settings.
In any MSDeploy scenario, what strategy can we use to prevent the target IIS settings from getting walked on by Development server settings? My first thought is, IIS first looks for site.config which would contain system.webService, then web.config updates/overrides any of those, ie <handler remove key="xxx" /> and so forth. Is this only solvable by XDT transforms?
In my opinion, the best solution to solve this is using web.config XDT transforms.
Since web.config file will also be published when deploy to the IIS server. If you have set the anonymousAuthentication setting in the web.config, it will use web.config setting instead of your server default setting.
Here is another solution(It will show the error page):
If you don't want to let the web.config to modify the default IIS setting, you could modify the feature delegation to disable override the setting from web.config.
You could find it from the IIS management feature:
Select read only:
Notice:
If you modify the Anonymous Authentication from the web.config. You will face below error:
I need help regarding spring security cookie path.
We have 2 web applications running in tomcat, app1 and app2. Both using the same domain, like www.company.com/app1 and www.company.com/app2 . Everything working fine and perfectly in tomcat.
But when we migrate to WebSphere, it started give issue. The issue is when a user login to app1, app2 cookie got overwritten because WebSphere storing the cookie in root path / and both applications using the same domain will overwrite another application cookie. In tomcat it storing in application path like /app1 and /app2 so no problem.
I am able to configure the WebSphere to make it work by configuring the application cookie path. Please see https://serverfault.com/questions/461518/websphere-jsessionid-cookie-overwrite-between-two-apps-on-the-same-domain-diffe for how to configure in WebSphere.
Now my question is, I don’t want to configure this in WebSphere. How can I do this in application level like configure the Spring Security xml or any other place. We want to make this in application level is because it will more portable and behave same in all containers.
I have try to configure the web.xml by adding the following but it not working.
<session-config>
<session-timeout>720</session-timeout>
<cookie-config>
<name>JSESSIONID</name>
<path>/app1</path>
<http-only>true</http-only>
<secure>true</secure>
</cookie-config>
</session-config>
I created an ExtJS 5 application with Sencha Cmd.
I will deploy this application in a tomcat server where there are some REST web services.
I would need to use these web services but when I run the application with "sencha app watch" (on port 1841) it doesn't find the services because they are on a differente server (tomcat is on a different port).
How can I use an "external" web service with Sencha CMD?
Thanks
stefano
Here are some of the available options:
Option 1 Proxy Web Service
You could create a service on the local machine where the sencha app is that create web requests that then goto the target remote services. This is called a proxy service.
Essentially the proxy service will take a request and resubmit it to the desired target remote machine.
There is a php example here
And a C# web request example here (Although this c# example isn't exactly what you are needing. The base of the web request that would need to be submitted is in this code. )
Option 2 JsonP
The other option off the top, is if the web services on the other machine support jsonp they should be accessible. However, jsonp only supports get so if you have a full rest implementation some services will probably not work.
More information on jsonp
And an extjs request example for JsonP:
Ext.data.JsonP.request({
'url': 'url',
params: {
'param1': 'value'
},
success: function (result, request) {
//success
}
});
Option 3 Hosting multiple apps/paths on single port
However, since it seems like the tomcat server may actually be on the same machine. Is there not a way to host both the web services and the application path through tomcat?
It looks like, for instance, jetty has an option to host two apps on the same port
Option 4 Enable CORS
You can enable cross origin resource sharing on the rest application depending on the architecture/framework used.
The browser will basically send a request first to see if it can access the resource. And then the server would respond with the allowed origin domains. Once CORS is enabled then access could be granted between the two different ports/servers
Great site on CORS with instructions for enabling on most basic setups
Here is example documentation for spring
All of them are web services, but what's the difference?
WSDL (Web Service Description Language) is a standard notatation for describing a Web Service in xml.
DISCO is a tool for querying SOAP and similar services and extracting useful information from the WSDL provied.
EVENTs is a proposed standard which uses WSDL and extends WSDL to support publish subcribe type event driven processes.
WSDL:
WSDL is a markup language that describes the web service. In order to use this Web service, the Client application developers need to know the methods exposed by the Web service and the parameters to be passed to these methods. It is imperative that access to these methodologies is available at development time and it is just this need that WSDL addresses.
DISCO:
The Web Service Discovery Tool (DISCO) is used to discover the URLs of XML Web Services located on a Web server and saves documents related to each XML service on a local disk. The DISCO takes the URL and discovers and produce publishes discovery documents (.wsdl, .xsd, .disco and .dicomap files) as arguments. Some of the options available for use with this tool are:
/d[omain]:domain - Specifies the domain name to use when connecting to a proxy server that requires authentication
/nosave - Does not save the discovered document or results
/nologo - Suppresses the Microsoft startup banner display
/o[ut]:directoryName - Specifies the output directory in which to save the discovered documents. Current directory is the default one.
/p[assword]:password - Specifies the password to use when connecting to a proxy server
/proxy:url - Specifies the URL of the proxy server to use for HTTP requests.
DISCO is a tool, not a web service itself.
EVENT:
if you mean to WS-Eventing, see here.
UDDI- UDDI is a central directory. It will have web services listed from multiple domain and servers.
DISCO- Disco contain web services listed from one domain and server.By which particular web service can be selected.
WSDL- It describe the rules or grammar for the function that are exposed in the web services.
I have a C# .net webservice that I need to restrict access to. I already require my consumers to use a username and password to call the service. But, is there a way to restrict access to the actual asmx page and the WSDL? I would need to restrict access to the webservice by username/password and IP address. If a user did not have the correct credentials, I would not want them to know what webmethods exist in the webservice.
Can this be done though IIS? I know that I can restrict IP addresses through IIS, but can I also use usernames/passwords?
Is there any other way to do this outside of IIS, maybe using C#.net?
Well, since it's ASMX you have the entire ASP.NET runtime stack at your disposal.
Step #1 - managing the resource through .config
Apply a <location> tag for the resources you want secured. Assuming it's a single ASMX file you can simply do the following in your web.config:
<location path="MyWebService.asmx">
<system.web>
<!-- resource specific options will go here -->
</system.web>
</location>
Step #2 - authenticating your users
You need to decide how you're actually going to authenticate users. There are several ways to do this and several authentication standards you could leverage. You need to pick the approach that's the right fit for you.
If you're on an intranet and are using Windows authentication I would highly suggest leveraging that because it's truly the simplest option to get setup. However, if your services are being accessed over the internet then Windows authenticatio is not really an option and you need to choose from a web standard. The simplest of those is Basic Authentication, but you should only use this over SSL since the username/password are not encrypted (only base64 encoded). The next step up from that is Digest authentication which doesn't require SSL because the username/password are sent using an MD5 hash. For the ultimate you can go with SSL v3 where you issue a specific client certificate to each user of your API.
Now, which option you select for security dictates what else needs to be done. If you choose Windows security, it's as easy as adding the following element to the <system.web> element we started with in Step #1:
<authentication mode="Windows" />
The remainder of the security protocols are going to require a little more work. ASP.NET doesn't provide intrinsic support for Basic, Digest or SSL v3. Technically you can leverage IIS to do this type of authentication for you, but it's always going to map to a Windows user. If that's an option for you, then simply leave the <authentication mode="Windows" /> element and configure IIS accordingly. If, however, that is not an option, either because you simply have no control over IIS/ActiveDirectory or you need to authenticate against a custom user database, then that means that you need to hook up a custom HttpModule to provide support for these security protocols.
Step #3 - securing the resource
The simplest approach to securing the resource is to basically say: "don't let anyone who hasn't successfully authenticated in some way into this resource". This is done using the following authorization configuration:
<authorization>
<deny users="?" />
</authorization>
If you wanted to only allow certain users you could change to do the following instead:
<authorization>
<deny users="*" />
<allow users="jdoe, msmith" />
</authorization>
Another approach is to define roles (groups) and simply lock the resource down to a special role which you put the users who you want to access the resource into.
<authorization>
<deny users="*" />
<allow roles="My Service Users" />
</authorization>
This maps well to Windows authentication because you can just setup a Windows group and let your MIS team manage which users are in that group using ActiveDirectory. However, the feature also works just fine for non-Windows authentication assuming the security implementation you've used exposes roles via its IPrincipal implementation.
I don't know how practical this is for you, but you could consider upgrading to WCF. WCF is fully backward compatible with ASMX web services, and lets you control whether or not the WSDL is exposed by defining a MEX (metadata exchange) endpoint. No MEX endpoint, no WSDL.
You can stop WSDL being shown by removing the Documentation protocol from the element in Machine.config
Update:
Web Services authentication - best practices?
If your users have usernames/passwords you can use HTTP basic authentication via HTTPS.
You can also implement it in a slightly differnt way. The first call to your web service should be the authentication method. Client authenticates and receives an authentication token. This token should be presented to all other methods exposed by your web service.
Two options: Create an entirely different site on a different port with locked down permissions. This has the advantage of providing some amount of "security through obscurity" (half joking...) Or you can add a new Application under your site(same port, different path), on a different app pool and assign permissions that way.
In either case, your web service isn't going to be able to talk with the various ASP.NET "things" like the application object (well it will, but it won't be the same one). Deployment is only slightly harder: deploy the same binaries, but only include the one web service file.
You can authenticate using an HttpModule.
SSL + BasicAuthentication should yield the best interop with other tool chains.
In the HttpModule, you have access to the request and can deny unauthenticated users access to just .asmx requests. And even then you might let them access the WSDL.
Add <add path="*.asmx" verb="*" type="System.Web.HttpForbiddenHandler" validate="True" /> to the <httpHandlers> section of the web.config file