Open Source Windows Frameworks

Secure, context-aware access that just works. Access internal resources securely. Implement zero trust. Achieve compliance. All without the headache of a VPN. For teams that prefer a hosted solution while keeping data governance. For organizations that need advanced scaling, access control, and governance capabilities. IT and developers need a scalable access control solution to keep users productive, happy, and secure. Pomerium uses identity and context to ensure secure access to internal applications, servers, and infrastructure even from untrusted networks. Pomerium adds authentication and authorization to any application or server, giving IT Management a centralized panel for organization-wide control. Assert compliance in your current architecture without giving up control over data tenancy. Pomerium supports your infrastructure and can be deployed in all environments: cloud, hybrid, or on-prem. From AWS to Kubernetes and more, your internal and 3rd-party apps are covered.

Fabio is an HTTP and TCP reverse proxy that configures itself with data from Consul. Traditional load balancers and reverse proxies need to be configured with a config file. The configuration contains the hostnames and paths the proxy is forwarding to upstream services. This process can be automated with tools like consul-template that generate config files and trigger a reload. Fabio works differently since it updates its routing table directly from the data stored in Consul as soon as there is a change and without restart or reloading. When you register a service in Consul all you need to add is a tag that announces the paths the upstream service accepts, e.g. urlprefix-/user or urlprefix-/order and fabio will do the rest. Fabio was developed and maintained by Frank Schröder through January, 2020. Since that date primary maintenance has been the responsibility of ENA and the great community of users.

glider is a forward proxy with multiple protocols support, and also a dns/dhcp server with ipset management features(like dnsmasq). We can set up local listeners as proxy servers, and forward requests to internet via forwarders. Act as both proxy client and proxy server(protocol converter). Flexible proxy & protocol chains. Load balancing with the following scheduling algorithm, rr: round robin, ha: high availability, lha: latency based high availability, dh: destination hashing. Rule & priority based forwarder choosing: Config Examples. DNS forwarding server. Force upstream querying by TCP. Association rules between dns and forwarder choosing. Association rules between dns and ipset. dns cache support. Custom dns record. IPSet management (linux kernel version >= 2.6.32). Add ip/cidrs from rule files on startup. Add resolved ips for domains from rule files by dns forwarding server. Serve HTTP and socks5 on the same port. Periodical availability checking for the forwarder.

Athens provides a server for Go Modules that you can run. It serves public code and your private code for you, so you don’t have to pull directly from a version control system (VCS) like GitHub or GitLab. There are many reasons why you’d want a proxy server such as security and performance. Athens is a project building on top of vgo (or go1.11+) trying to bring dependencies closer to you so you can count on repeatable builds even at a time when VCS is down. The big goal of Athens is to provide a new place where dependencies — not code — live. Dependencies are immutable blobs of code and associated metadata that come from Github. They live in storage that Athens controls. You probably already know what “immutable” means, but let me just point it out again because it’s really important for this whole system. When folks change their packages, iterate, experiment, or whatever else, code on Athens won’t change.

Asterisk Manage API and FAGI C++ Framework. Implemented with high efficient OS independent Sockets wrapper (ACE). Provide C++ API wrappers for Asterisk Manager API and FAGI. A Manage API relay(proxy) server and a FAGI socket server will be implemented.

A toolkit to create code-first HTTP Reverse Proxies hosted in ASP.NET Core as middleware. This allows focused code-first proxies that can be embedded in existing ASP.NET Core applications or deployed as a standalone server. Deployable anywhere ASP.NET Core is deployable such as Windows, Linux, Containers and Serverless (with caveats). Having built proxies many times before, I felt it is time to make a package. Forked from ASP.NET labs, it has been heavily modified with a different API, to facilitate a wider variety of proxying scenarios (i.e. routing based on a JWT claim) and interception of the proxy requests/responses for customization of headers and (optionally) request/response bodies. It also uses HttpClientFactory internally that will mitigate against DNS caching issues making it suitable for microservice/container environments.

docker-gen is a file generator that renders templates using docker container meta-data. Centralized logging - fluentd, logstash or other centralized logging tools that tail the containers JSON log file or files within the container. Log Rotation - logrotate files to rotate container JSON log files. Reverse Proxy Configs - nginx, haproxy, etc. reverse proxy configs to route requests from the host to containers. Service Discovery - Scripts (python, bash, etc..) to register containers within etcd, hipache, etc. Docker-gen can be bundled inside of a container along-side applications. nginx-proxy/nginx-proxy trusted build is an example of running docker-gen within a container along-side nginx. jwilder/docker-register is an example of running docker-gen within a container to do service registration with etcd.

gRPC-Gateway is a plugin of protoc. It reads a gRPC service definition and generates a reverse-proxy server which translates a RESTful JSON API into gRPC. This server is generated according to custom options in your gRPC definition. gRPC-Gateway helps you to provide your APIs in both gRPC and RESTful style at the same time. gRPC is great -- it generates API clients and server stubs in many programming languages, it is fast, easy to use, and bandwidth-efficient and its design is combat-proven by Google. However, you might still want to provide a traditional RESTful JSON API as well. Reasons can range from maintaining backward compatibility, supporting languages or clients that are not well supported by gRPC, to simply maintaining the aesthetics and tooling involved with a RESTful JSON architecture. This project aims to provide that HTTP+JSON interface to your gRPC service.