MediaWiki API result

This is the HTML representation of the JSON format. HTML is good for debugging, but is unsuitable for application use.

Specify the format parameter to change the output format. To see the non-HTML representation of the JSON format, set format=json.

See the complete documentation, or the API help for more information.

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "SWMM5-Python",
        "continue": "gapcontinue||"
    },
    "warnings": {
        "main": {
            "*": "Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes."
        },
        "revisions": {
            "*": "Because \"rvslots\" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used."
        }
    },
    "query": {
        "pages": {
            "1888": {
                "pageid": 1888,
                "ns": 0,
                "title": "Remote Editing in UNIX",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "[[Image:WinSCP_explorer.png|thumb|The WinSCP Explorer|400px]]\n[[Image:WinSCP_editor.png|thumb|A Remote edit window|400px]]\nUnlike Windows, UNIX computers were always meant to be accessed both locally (in front of the computer) and remotely (from somewhere remote). Even with today's high speed network communications, editing with a graphical editor like [[wikipedia:gedit|gedit]] over the network can be a tedious experience. You hit a button and wait ages for the user interface to be updated!. Of course if you are comfortable with vim or emacs editors which don't need any graphical interface, they you are fine. But for those who don't know these, there is [[wikipedia:WinSCP|WinSCP]].\n\n==How it works==\nWell.. rather simple. Let's think of a scenario. You can log in to a UNIX server in [[wikipedia:Tasmania|Tasmania]] and you live in [[wikipedia:Turkey|Turkey]]. The network speed is so low that it is not possible to invoke a fancy editor that is available in the server. One thing you can do is to use [[wikipedia:FTP|FTP]] (or any other file transfer method) to get a copy of the file to your local (let's say windows) computer, edit the copy and send the new version back to  the server. Problem solved! But this is a lot of work and if you want to edit 100 files and each file has to be edited dozen times, this is going to kill you! What [[wikipedia:WinSCP|WinSCP]]  does is simply automate this entire process. \n\nThere is a [[wikipedia:Windows Explorer|Windows Explorer]] like interface that shows files in the remote server and when you double click on a file it will be copied to your local machine and opened in the editor. Whenever you hit the 'Save' button on the editor, the program updates the changes in the remote copy on the server. \n\n;WinSCP website: [http://winscp.net winscp.net]"
                    }
                ]
            },
            "1312": {
                "pageid": 1312,
                "ns": 0,
                "title": "SSH login without passwords",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "==Synopsis==\n{{wbox|;IMPORTANT:\nThe method described here has inherant problem of sever being vulnarable if the client is compromised.  There is no line of defence in between. This arises from the fact that we don't enter a pass-phrase when creating the key-pair. To overcome this issue, without going through the trouble of entering a password (or phrase) at every login, use the application known as [[Keychain]].}}\nWhenever the ssh command is used to login to a remote machine, user needs to provide the remote machines password. While this is an obvious security precaution, it soon becomes a headache once you start to login fifty-times a day to the same, known-and-trusted server from your known-and-trusted client! For such situations, the following is a good approach.\n\n==Howto==\n;Note:Let's assume the client and server names are <nowiki>\n</nowiki><pre><nowiki>\nclient1\nserver1\n</nowiki></pre>respectively and username in the server (remote machine) is <nowiki>\n</nowiki><pre><nowiki>\nuser1\n</nowiki></pre>. \n#Create public-private key pair in client1<nowiki>\n</nowiki><pre><nowiki>\n$ ssh-keygen -t dsa -f ~/.ssh/id_dsa\nGenerating public/private dsa key pair.\nEnter passphrase (empty for no passphrase): (Don't type anything, just press enter here.)\nEnter same passphrase again: (Again empty)\n52:da:75:66:09:15:5e:cb:6f:a3:xd:39:rd:15:f6:da user@client1\n</nowiki></pre>\n#Copy public-key to somewhere in server1<nowiki>\n</nowiki><pre><nowiki>$ scp ~/.ssh/id_dsa.pub user1@server1:~/.ssh/id_dsa.pub</nowiki></pre>\n#In the server1, append the public-key for client1 to the authorized-keys file<nowiki>\n</nowiki><pre><nowiki>cat ~user1/.ssh/id_dsa.pub >> ~user1/.ssh/authorized_keys2</nowiki></pre>\n#Secure the authorized-keys file (otherwise the scheme will not work!) and remove unnecessary files. (in server1) <nowiki>\n</nowiki><pre><nowiki>\n$ chmod 640 ~user1/.ssh/authorized_keys2\n$ rm ~user1/.ssh/id_dsa.pub\n</nowiki></pre>.\n\n\nNow you should be able to login from client1 to user1@server1 without providing password.\n\n[[Category:Unix]]"
                    }
                ]
            }
        }
    }
}