Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "x509"
-
New twist on an old favorite.
Background:
- TeamA provides a service internal to the company.
- That service is made accessible to a cloud environment, also has a requirement to be made available to machines on the local network so you can develop against it.
- Company is too cheap/stupid to get a s2s vpn to their cloud provider.
- Company also only hosts production in the cloud, so all other dev is done locally, or on production non-similar infra, local dev is podman.
- They accomplish service connectivity by use of an inordinately complicated edge gateway/router/firewall/message translator/ouija board/julienne fry maker, also controlled by said service team.
Scenario:
Me: "Hey, we're cool with signing requests using an x509 cert. That said, doing so requires different code than connecting to an unsecured endpoint. Please make this service accessible to developer machines and lower environments on the internal network so we can, you know, develop."
TeamA: "The service should be accessible to [cloud ip range]"
Me: "Yes, that's a production range. We need to be able to test the signing code without testing in production"
TeamA: "Can you mock the data?"
Me: "The code we are testing is relating to auth, not business logic"
TeamA: "What are you trying to do?"
Me: "We are trying to test the code that uses the x509 you provide to connect to the service"
TeamA: "Can you deploy to the cloud"
Me: "Again, no, the cloud is only production per policy, all lower environments are in the local data center"
TeamA: "can you try connecting to the gateway?"
Me: "Yes, we have, it's not accessible, it only has public DNS, and only allows [cloud ip range]"
TeamA: "it work when we try it"
Me: "Can you please supply repro steps so we can adjust our process"
TeamA: "Yes, log into the gateway and try issuing the call from there"
Me: (╯°□°)╯︵ ┻━┻
tl;dr: Works on my server -
I'm in need of advice. I reckon this is no stack overflow but that's probably for the best as I wouldn't feel as comfortable posting there as I am doing it here. So, back to the question: I'm currently working with legacy code, written in .NET 2.0. This code is responsible for calling upon PEC services in order to finally create personal smart cards. I was tasked with the job of creating a repository system that would allow the program to call on the old legacy services or the new ones without any distinction. We are talking about SOAP services in both cases. The issues is: the new service definition is comprised of soap policies. This wouldn't be a problem per se, with more modern version of the framework, but with .NET 2.0? Yes, it is. It doesn't support policies and signing the body with a certificate right out of the box. How can I manage this? I feel like the only way would be letting the proxy class do its thing up until the very last moment: intercept the SOAP request before its sent and modify it according to the specifications. But I reckon this is very bad practice. Is there any other way out of this?
Thanks for anyone that would like to help. 🙂6