I have a specific protocol specification I am writing to that utilizes a Station to Station Protocol for authentication. Thus far I've been using Twisted web and the Resource class along with render_GET, render_POST, but once the authentication step is complete with my client the communication is encrypted, even at the HTTP protocol level. That is I lose visibility to GET /resource and only receive encrypted bytes on the TCP session. I tried looking at intercepting the render method but it is not called if there is no HTTP method parsed. Is it possible to use Resource still or do I need to "downshift" to using HTTPChannel and its ability to hand me raw data?
Related
I'm about to use Python.requests to get data from my own online api to my local pc. My api requires authentication which for now is done trough simply posting user/pass:
params = {'user': 'username', 'pass':'password'}
requests.post(url, params=params)
Are this requests safe or is it going to allow a middle-man to capture that user/pass?
P.S My api is using a letsencrypt ssl certificate. Python version 3.7.0
this has nothing to do with the python-requests package, but with the HTTP (and HTTPS) protocols. HTTP is plain-text so anyone that manages to sniff your packets can read the content (hence the username/password pair in clear text). HTTPS uses strong encryption, so even someone sniffing your traffic will have a hard-time deciphering it - no encryption scheme is 100% safe of course but decrypting SSL traffic is currently way too costly even for the NSA.
IOW, what will make your requests "safe" is the use of the HTTPS protocol, not which python (or not python) package you use to write your client code.
Use the HTTPS protocol and it's safe provided you have a valid SSL certificate on your api. If you still feel paranoid/insecure, you can implement end-to-end encryption using an existing algorithm or create your custom algorithm either.
I have a service that can make SAP RFC requests to some server. Assume that I can not modify this service, but need to handle such requests and process their data.
So I want to develop my own server that will process RFC requests, I prefer Python but can do it with C++ too.
I read that it should be possible to do with PyRFC
https://sap.github.io/PyRFC/server.html#server-server
but there are "gateway parameters" and I don't know what I should use here, and in my concept I do not need SAP Gateway here, I just want to process requests in my standalone server.
Is it possible to develop own standalone server for processing RFC requests with Pyhton or C++?
Or it can be used only with SAP Gateway? In this case what I need to do in SAP Gateway side?
You will need a SAP Gateway server/service anyway - and by that, I don't mean the SAP Gateway product that is used to provide OData services, but the sapgw process that is part of the SAP NetWeaver Application Server ABAP installation. This process is required because your custom RFC server registers itself at a sapgw server (specifying an identifier in the process), and the sapgw instance will route outgoing (!) calls to your implementation based on the identifier that is specified in the RFC destination as well.
As for direct communication between non-SAP systems (so non-outgoing RFC calls) - that should be possible as well, but I strongly believe that the calling service will have to be adapted to the fact that it's not talking to a "real" ABAP back-end. You'll also have to mock the DDIC Repository access, the user authentication process, ... - realistically speaking, it might be easier to simply install an ABAP system and do the processing there.
The situation is this one: a client authenticates to a server using a signed certificate. Then a complete handshake is performed and the data are exchanged in a secure manner.
But depending on a number of elements, I need to associate each user to a specific server (many users can share the same server). The context can change in any instant and I want to be able to change this user -> server map without having to access the user device.
The most straightforward way seems to be the implementation of a gateway/router which uses the information from the client certificate to handle the routing.
The problem with that is that I have no idea of how to make such a router without resorting to MITMing (which I don't want for computational, security and privacy reasons): AFAIK, the ssl lib and openssl bindings in Python (which are fast, reliable and widespread) only provide wrapped sockets which handle the decryption part. There seems to be no public interface just to extract the certificate and forward the pristine stream to a suitable backend server.
Do you know any way to get that certificate and forward the complete, unaltered, stream to another server without resorting to complicated schemes/workarounds?
I want to send a request to a server which is a private protocol based on TCP (Not HTTP), How Can I send a request using Python?
Python sockets are what you are looking for. Take a look at the Python Socket class at https://docs.python.org/2/library/socket.html
This site includes examples of how to set up a server and client and provides a basic example of the fundamental TCP Communication using Python. If you need something with more control you may want to look at Scapy: http://www.secdev.org/projects/scapy/
Scapy is a python implementation that provides a framework to control almost all aspects to Network Communication all the way down to Layer 2 (Ethernet Frame).
I'm having a difficult time fully understanding the nature of a TCP server/client relationship when a JSON string is sent to the server. The information I need may be out there, but I'm perhpas not using the correct search paramaters as I'm looking.
I've built a Python TCP, JSON-RPC Server from the following examples:
https://github.com/joshmarshall/jsonrpclib
http://code.activestate.com/recipes/552751-json-rpc-server-and-client/
In both cases, I can communicate with the Python server from a Python console on a different computer, sending commands from one (the client) to the other (server). In all of the examples, I've had to install the libraries mentioned above on both the client and the server machines in order to facilitate the TCP communication.
So the background to my situation and question is, when does JSON enter the mix? This is what I want to do:
Setup a Python TCP server that accepts a JSON string from a remote client inside (or outside) the network. The server parses the JSON string, fetches the method and parameters from the objectified string, and executes the method. The server then sends a JSON string result to the calling client. In this case, the client is a mobile application (iPad, Android, etc) with a JavaScript library that I'll use to send the requests to the server.
Why would I need a Python client? From what I can gather, the client just needs to open a connection to the server and then send the JSON string, right? Why do all the code samples include Python client examples? Are they assuming a server machine is going to talk to a server machine, so they have included client code to help generate the JSON string that will be sent to the server?
If I assume that a Python client isn't really needed for anything, I've been sending JSON strings to the Python server from the iPad, but in each case the server is reporting a "Bad request syntax" error. I'll pen a new question on that issue if I'm understanding the current question correctly.
Insight is appreciated.
The JSON encoding is the lingua franca of your RPC protocol, so you can indeed use any client you like. The implementations you found for JSON-RPC use the HTTP protocol, a very specific communication protocol built on top of TCP/IP, but you can implement the same protocol over raw TCP-IP sockets if so required.
The examples include both the Python client and the server because they illustrate how to implement the JSON-RPC standard in Python, not in JavaScript or C or Lisp. They focus on the implementation in one language. The JSON-RPC standard however, is language agnostic. It doesn't matter what language you write either the server or the client in, as long as they use the same standard.