Python emulation Login Cnblogs

Python simulates browser login with Requests.session object cnblogs

Request. Session-to-row can be used to persist cookies across requests and is very handy for simulating logins.

Cnblogs Login Page Analysis:

Login Page Https://passport.cnblogs.com/user/signin

Use the Grab Kit tool fiddler (Wireshark cannot be crawled) to crawl to the log-in post data:

A total of three fields are INPUT1, Input2, and remember (user name, password, whether to remember login information).

Among them, INPUT1 and Input2 are encrypted ciphertext after RSA.

To remember the login status, we also need to crawl the cookie (note that to crawl the page's cookie):

After catching the above required data, you can simulate the browser to log in to Cnblogs, the specific code is implemented as follows:

#!/usr/bin/python#_*_ coding:utf-8 _*_ImportREQUESTSS=requests. Session () Headers={        'Accept':'Application/json, Text/javascript, */*; q=0.01',        'user-agent':'mozilla/5.0 (Windows NT 6.3; WOW64) applewebkit/537.36 (khtml, like Gecko) chrome/39.0.2171.95 safari/537.36',        'Referer':'Https://passport.cnblogs.com/user/signin',        'Cookies':'. Cnblogscookie= b1cb9d692bdf8ce3e5e16c879498ab7e4624caxxxxxxxxxx4c494c503e65a81b35bbd5c05991503e855c0b917df1fa1b6c2855821aae66f474c555653 fd8812c6bea6235fc15e6e6963abf3716f8b3d8d4b840;_ga=ga1.2.372503701.1486351394'}log_data={        'INPUT1':'n8utcfvfkedcjtr2uxy2xtwwvfjx/xxxxxxxxxxw1grgy1w13otnjgsb6ojcd0n9mhmzbnlp6/jxmryq5wvuk/ uow98x1zdmtb4k3umlelq9ugihckdxvheriflvvxofcapsmudzt5ir09k4svptrmo6mdhlkek4qsddl3ejfnju=',        'Input2':'b5djzewpm2i06icgiaje8su4ylrvrxxxxxxxxim4zqcf+wxhjw3zw9emfkizs0zalntngg441vjiigzzdx/ mzmwpmrp9j2ydiqd7buwlsiyc2zv4s4thjzp5vgqqxrlbf+kfogusq2vjl1umfc2s1fsd8i3wdzuol23t0a30=',        'Remember':'false'}url='Https://passport.cnblogs.com/user/signin'req=s.post (url,data=log_data,headers=headers)PrintReq.status_codePrintReq.content.decode ('Utf-8') F=s.get ('http://www.cnblogs.com/ahaii/diary/2016/01/28/5167172.html', headers=headers)#View a journalPrintF.status_codePrintF.text

Add:

1, about HTTPS encryption:

HTTPS is HTTP+SSL encrypted transmission, using 443 ports to encrypt the transmitted data.

Symmetric and Asymmetric Encryption:

Symmetric encryption: Data sending and receiving end use the same private key, less secure.

Encryption: PlainText + algorithm + private key = Cipher decryption: cipher + algorithm + private key = Clear text

Asymmetric encryption: Data is sent and received using a pair of keys (public and private) to encrypt the data, the pair appears. Public key is public, private key is saved.

Ciphertext encrypted by the public key can only be decrypted with the private key:

Encryption: PlainText + algorithm + Public key = Cipher decryption: Ciphertext + algorithm + private key = Clear text

Ciphertext encrypted by the private key can only be decrypted with the public key:

Encryption: PlainText + algorithm + private key = Cipher decryption: Ciphertext + algorithm + Public key = Clear text

2, about the HTTPS connection establishment process:

Three keys are involved throughout the process

• Server-side public and private keys for asymmetric encryption
• A random key generated by the client, used to encrypt the data symmetrically

1. The client initiates an HTTPS request, and after the user enters an HTTPS URL, access the server's 443 port
2. The server side has a key pair, that is, the public key and private key, is used for asymmetric encryption, the server side holds the private key, cannot be disclosed, the public key can be sent to anyone.
3. Transfer the certificate, which is the public key, that the server passes the public key to the client.
4. The client resolves the certificate, and the client receives the public key from the server to verify its validity, and if there is a problem with the public key, it cannot carry out HTTPS transmission, the public key is the digital certificate sent by the server. If there are no problems, a random value is generated, which is the key for symmetric encryption. This random value (that is, the client private key) is then asymmetric encrypted with the public key sent by the server, so that the first HTTP request in HTTPS ends.
5. The client initiates a second HTTP request in HTTPS and sends the encrypted client key to the server.
6. After the server receives the ciphertext from the client, it uses its own private key to decrypt it, and the decrypted plaintext is the client key, then the data is symmetric encrypted with the client key, so the data becomes ciphertext.
7. The server then sends the encrypted ciphertext to the client.
8. The client receives the ciphertext sent by the server, and uses the client key to decrypt it, and obtains the data sent by the server. So the second HTTP request in HTTPS ends and the entire HTTPS transfer is complete.

Python emulation Login Cnblogs