I have a c#-based program that can send messages and files to our SlackWorkspace via my SlackApp (I'm using HttpClient to communicate with Slack).
Now, to distribute this program in my workspace and to make it so that every user will have his own identity, it says that I have to use OAuth and create verification-tokens, specific for each user.
It says in the Slack-documentation I have to use a redirect-URL (as per docs) to my own server.
We have a server that I potentially could use for this. But I have never done anything like this before and I am unclear on what "answer" I have to provide from our server. I thought the verification-process would be handled by Slack.
Anyone has an idea on how to approach this?
And before anyone asks - yes we need to install it for everyone and make them identifiable as themselves. We can't use the "SlackApp" as user. :)
I would be very grateful for code examples(in c#) and explanations on how this whole redirect-thing is working.
Slack uses the standard Oauth 2.0 protocol to authenticate apps, similar to Google and Facebook.
So the "verification-process" is indeed mostly handled by Slack (as outlined here), but your Slack app needs to initiate it and handle the responses properly. Also its a multi-step process and includes the user having to login into Slack with their credentials. This why you need a web app to handle the whole process.
To enable a Slack app to generate tokens via Oauth a web app is needed:
can be reached from the Internet
able to handle HTTP requests like a web server
has persistent storage for the newly generated tokens
This is probably easier to implement with ASP.NET Web Pages, which can utilize many functions from an existing web server.
But for this answer, lets look on an implementation in .NET Core. For that we need to create our own web server and some rudimentary session handling. Main concepts include:
HttpListener class for providing fundamental ability to listen and respond to HTTP requests
Handle multiple requests in parallel
Cookies / Session handling
MD5 hashes
The details go a bit beyond the scope of one answer. But I am happy to share a working example implementation on this GitHubGist.
Btw: For the local development of such a web app its recommend to use a VPN tunnel like ngrok, that allows one to expose a local machine securely to the Internet and Slack.
Custom table's data hangs on the loading screen after saving any changes. This is happening on some of tables and it seems that the majority of records are saved, however I have noticed a couple that didn't save within some custom table until reapplying the change!
I was wondering what can cause the issue.
I have found the issue using browser's developer tools.
Issue
Clicking save button was creating
Mixed Content: The page at 'https://address' was loaded over HTTPS, but requested an insecure form action 'http://address'. This request has been blocked; the content must be served over HTTPS. JS error on the browser and browser was blocking the content. However, the form action was not pointing to absolute URL address.
Solution
As the server SSL config was fine, therefore, there was not any other way than changing core CustomTableForm.ascx.cs Kentico file. Although it is not recommended. The problem solved by developing RedirectUrlAfterSave property of customTableFormobject to make sure it will redirect correct protocol instead of Absolute URL
Hope it will help you guys.
This was just brought to my attention, not sure how I missed it before. So, I will post my answer just for the future reference :-)
I guess there is some SLL offloading going on before the actual IIS where Kentico is running. In this case, SSL Accelerator must be implemented. The link goes to Xperience 13 version but the same idea applies for older versions. Just use the version selector in the top bar - there could be some API differences.
And the same applies e.g. when uploading media files - the browser console will show mixed content warning. This is for security reasons. Browser sees the HTTPS but behind the offloader there is HTTP communication and the GetAbsoluteURL method takes the protocol from the request. Thus, mixed content. Using the ssl accelerator will tell Kentico to use HTTPS internally.
I am making a webservice that only needs to serve json and it needs to be scalable.
I have gotten the impression that Nginx is a more scalable webserver than IIS 7.5 and that it is extremely simple to manage compared to IIS. Also, Nginx can very easily be used to load balance among several json services, using the upstream module.
As I only need to serve json I feel that ASP.Net and IIS i way overkill. I just need some very simple routing and a simple authcookie mechanism I easily can write myself.
Right now I am using MVC3 but feels it is to bloated when I only servce Json, and I am very annoyed by the facts that I am having to write custom Auth attributes to make a default deny policy, having to make a HttpModule to hack around WindowsFroms authentication's default redirection of unauthorized requests and in general needs to read and learn a lot to stay in control of the framework. I have also considered WCF but my prev. experience with this was that there was to much bloat and configuration for my needs and to much stuff to know about to stay in control.
I prefer simplicity and want to avoid "framework overhead" when I just need to handle some Http for a simple, fast and scalable async json service. So I am considering a setup like this:
An Nginx webserver on a linux box that load balances among and proxies webrequests to async json services.
The json services are written as Windows Services using HttpListener to do Async handling of web reqests.
What are your thoughts about this architecture ?
EDIT: Actually I think it would be more performant using fastcgi from nginx to the windows services instead of proxying http prequests ? What are your thoughts ?
Just implement an ASHX - basically a IHttpHandler for IIS which scales really well and most of the issues you describe just "go away"... it gives you full control over the whole request/response processing... for a nice tutorial see http://www.dotnetperls.com/ashx
My feeling is that it would be more than sufficient to configure a simple web application that has one request handler that returns the relevant Json response.
You may want to look at optimising the ASP .NET pipeline. You can read more about this and other ASP .NET optimisations here. If the request handling is lightweight from a processing perspective, you may also want to bump up the thread limits. This is also covered in the article referenced.
From an Nginx point of view, you may want to check that number of worker threads matches your CPU count.
Hope this helps.
I'm relatively new to proxies.
I am currently required to design a caching proxy for work.
We have a webservice which serves up data based on calls to it, naturally.
I am required to create a proxy for a rich client application that caches the results of these calls.
The results are basically string names of products identified by a composition of ids.
I could just create a class that acts as my proxy client that caches the results in a cache, I was thinking of using the System.Web.Caching.Cache object.
However I thought I'd ask to see if there are any design aspects and considerations that I have missed. Is there a design that is commonly known that I have not found?
[UPDATE - 12 Oct 2009]
Seems like System.Web.Caching.Cache is not advisable for client side caching.
http://msdn.microsoft.com/en-us/library/system.web.caching.cache.aspx:
The Cache class is not intended for
use outside of ASP.NET applications.
It was designed and tested for use in
ASP.NET to provide caching for Web
applications. In other types of
applications, such as console
applications or Windows Forms
applications, ASP.NET caching might
not work correctly.
First, I've used System.Web.Caching.Cache in Winforms and Service solutions and never had a problem with it. I recommend mitigating against the disclaimer by testing to ensure the cache works and doesn't leak resources, but none of my testing ever showed this happening.
Alternatively there is a caching solution in Enterprise Library, and probably a bunch of other open source ones you could consider. And there are probably some commercially supported ones too if you prefer.
However, are you hosting your web service in ASP.Net (.asmx extension is usually a good indicator). In that case your still in ASP.Net and so the disclaimer shouldn't apply.
Also note that ASP.Net has caching options you can drive directly from the web.config without having to do any coding.
But all of the above is server side caching.
Assuming your web service is using HTTP (or HTTPS) as the transport layer, then proxy and client caching require use of the HTTP response headers, I think Cache-Control, Expires and possibly Last-Modified are involved. Then it is up to the client and proxies to decide whether they will support caching or not.
Alternatively if your actually trying to write a proxy solution that supports caching (and that would be rewriting a wheel so you should have a good reason to do this) then you probably want a HTTP Handler, with the System.Web.HttpRequest and System.Web.HttpResponse representing the client side of things, and passing the request through to the server using System.Net.HttpWebRequest and System.Net.HttpResponse. The System.Web.Caching.Cache could then support your cached responses on your proxy. That said there would be lots of rules to have to implement here, including HTTP Request headers (also has Cache-Control options).
Disclaimer: I've tried Googling for something that will do what I want, but no luck there. I'm hoping someone here might be able to lend a hand.
Background
I have a .NET class library that accesses a secure web service with the WSE 2.0 library. The web service provides a front-end to a central database (it's actually part of a data-sharing network spanning multiple customers) and the class library provides a simple wrapper around the web service calls to make it accessible from a legacy VB6 application. The legacy application uses the class library to retrieve and publish information to the web service. Currently, the application and class library DLL are both installed client-side on multiple workstations.
The Problem
The catch is that the web service we are accessing uses HTTPS and a valid X509 client certificate needs to be presented to the web service in order to access it. Since all of our components live on the client machine, this has led to deployment problems. For example, we have to download and install per-user certificates on each client machine, one for each user who might need to access the web service through our application. What's more, the web server itself must be accessed through a VPN (OpenVPN in particular), which means a VPN client has to be installed and configured on every client machine. It is a major pain (some of our customers have dozens of workstations).
The Proposed Solution
The proposed solution is to move all of this logic to a central server on the customer site. In this scenario, our legacy application would communicate with a local server, which will then go off and forward requests to the real web service. In addition, all of the X509 certificates would be installed on the server, instead of on each individual client computer, as part of the effort to simplify and centralize deployment.
So far, we've come up with three options:
Find a ready-made SOAP proxy server which can take incoming HTTP-based SOAP requests, modify the Host header and routing-related parts of the SOAP message (so they are pointing to the real web server), open an SSL connection to the real web server, present the correct client certificate to the server (based on a username-to-certificate mapping), forward the modified request, read the response, convert it back to plaintext, and send it back to the client.
Write a proxy server by hand that does everything I just mentioned.
Think of completely different and hopefully better way to solve this problem.
Rationale
The rationale for trying to find and/or write a SOAP proxy server is that our existing .NET wrapper library wouldn't have to be modified at all. We would simply point it at the proxy server instead of the real web service endpoint, using a plain HTTP connection instead of HTTPS. The proxy server will handle the request, modify it to so that the real web service will accept it (i.e. things like changing the SOAPAction header so that it is correct), handle the SSL/certificate handshake, and send the raw response data back to the client.
However, this sounds like an awful hack to me me at best. So, what our my options here?
Do I bite the bullet and write my own HTTP/SSL/SOAP/X509 aware proxy server to do all this?
Or...is there a ready-made solution with an extensible enough API that I can easily make it do what I want
Or...should I take a completely different approach?
The key issues we are trying to solve are (a) centralizing where certificates are stored to simplify installation and management of certificates and (b) setting things up so that the VPN connection to the web server only occurs from a single machine, instead of needing every client to have VPN client software installed.
Note we do not control the web server that is hosting the web service.
EDIT: To clarify, I have already implemented a (rather crappy) proxy server in C# that does meet the requirements, but something feels fundamentally wrong to me about this whole approach to the problem. So, ultimately, I am looking either for reassurance that I am on the right track, or helpful advice telling me I'm going about this the completely wrong way, and any tips for doing it a better way (if there is one, which I suspect there is).
Apache Camel would fit the bill perfectly. Camel is a lightweight framework for doing exactly this kind of application integration. I've used it to do some similar http proxying in the past.
Camel uses a very expressive DSL for defining routes between endpoint. In your case you want to stand up a server that is visible to all the client machines at your customer site and whatever requests it receives you want to route 'from' this endpoint 'to' your secure endpoint via https.
You'll need to create a simple class that defines the route. It should extend RouteBuilder and override the configure method
public class WebServiceProxy extends RouteBuilder
{
public void configure()
{
from("jetty:http://0.0.0.0:8080/myServicePath")
.to("https://mysecureserver/myServicePath");
}
}
Add this to a Camel context and you'll be good to go.
CamelContext context = new DefaultCamelContext();
context.addRoute(new WebServiceProxy());
context.start();
This route will create a webserver using jetty bound to 8080 on all local interfaces. Any requests sent to /myServicePath will get routed directly to your webservice defined by the uri https://mysecureserver/myServicePath. You define the endpoints using simple uris and the dsl and camel takes care of the heavy lifting.
You may need to configure a keystore with your certs in in and make it available to the http component. Post again if you've trouble here ;)
I'd read the camel docs for the http component for more details, check the unit tests for the project too as they are chock full of examples and best practices.
HTH.
FYI: To have the http component use your keystore, you'll need to set the following properties
System.setProperty("javax.net.ssl.trustStore", "path/to/keystore");
System.setProperty("javax.net.ssl.trustStorePassword", "keystore-password");
You should look into WCF, which supports the WS-Addressing protocol. I believe I've seen articles (in MSDN, I think) on writing routers using WCF.
You should also get rid of WSE 2.0 as soon as possible. It's very badly obsolete (having been replaced by WSE 3.0, which is also obsolete). All of its functions have been superceded by WCF.
I believe an ESB (Enterprise Service Bus) could be a viable, robust solution to your problem. There is an open source ESB called Mule, which I've never used. I did mess around with ALSB (AquaLogic Service Bus) a while back, but it would be expensive for what you are describing. Anyway, the thing that you would want to look at in particular is the routing. I'm not sure it would be a simple plug 'n play, but it is indeed another option.
You can also do this with Microsoft ISA Server, a commercial Proxy/Cache server. It will do many of the things you need out of the box. For anything that is not possible out of the box, you can write an extension to the server to get it done.
ISA Server is not free.
ISA is now being renamed to "Microsoft Forefront Threat Management Gateway".
It is much more than a web proxy server, though - it has support for many protocols and
lots of features. Maybe more than you need.
There is a service virtualization tool from Microsoft available on Codeplex called the Managed Service Engine which is intended to decouple the client from the web service implementation. It might fill the bill or give you a running start. I haven't really investigated it thoroughly, just skimmed an article in MSDN and your description reminded me of it.
http://www.codeplex.com/servicesengine
http://msdn.microsoft.com/en-us/magazine/dd727511.aspx
Your security model doesn't make sense to me. What is the purpose of using HTTPS? Usually it is to authenticate the service to the clients. In that case, why does the server need to keep the clients' certificates? It is the clients who should be keeping the server's X509 Certificate.
Why do you need to go through VPN? If you need to authenticate clients, there are better ways to do that. You can either enable mutual authentication in SSL, or use XML-Security and possibly WS-Security to secure the service at the SOAP level. Even if you do use SSL to authenticate clients, you still shouldn't keep all the client certificates on the server, but rather use PKI and verify the client certificates to a trusted root.
Finally, specifically for your proposed proxy-based solution, I don't see why you need anything SOAP-specific. Don't you just need a web server that can forward any HTTP request to a remote HTTPS server? I don't know how to do this offhand, but I'd be investigating the likes of Apache and IIS...