JP2006163581A - Log-in processing method, log-in processing program, and log-in processor - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To easily manage a user ID and a password in a Web system. <P>SOLUTION: The Web server extracts additional information from an access-requested URL, requests ID input to a client, determines whether an ID transmitted from the client in response to the request coincides with the extracted additional information, and performs log-in processing when it is determined that they coincide each other. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a login processing method, a login processing program, and a login processing apparatus for an information processing system that accesses a Web server.

Conventionally, when using an information processing system using the Web, a method is generally used in which it is assumed that the user has logged in by accessing a predetermined URL and inputting a predetermined user ID and password, and can be used thereafter. (For example, refer to Patent Document 1).
JP 2000-076327 A

  However, the Web system often targets a very large number of users, and in order to create and save user IDs and passwords for all users including trial users etc. It was a heavy administrative burden.

  On the other hand, when a specific user ID and password combination is used by many people, management is simplified, but there is a problem that it is vulnerable to illegal access due to information leakage.

  The present invention has been made paying attention to the above points, and can reduce the ID management work on the Web server side, and at the same time, can enhance the security and easily issue a different URL for each user. An object of the present invention is to provide a login processing method, a login processing program, and a login processing device.

  In order to solve the above problems, a login processing method according to the present invention includes a reception step of receiving a URL requested to be accessed, an extraction step of extracting additional information from the received URL, and a requesting step of requesting an ID input from a client. A determination step for determining whether or not the ID sent from the client in response to the request in the request step matches the additional information extracted in the extraction step; and And a login step for performing login processing.

  In one embodiment of the present invention, the ID entered by the user is not directly checked against the user management DB on the server side, but only when both the ID information embedded in the URL of the access request matches the ID entered by the user. You can log in.

  According to the present invention, the ID management work on the Web server side can be reduced and at the same time the security can be enhanced.

  According to the present invention, it is easy to issue a different URL for each user.

  Hereinafter, the best mode for carrying out the present invention will be described in detail with reference to examples.

  FIG. 1 shows a procedure for displaying a login panel on a Web browser when the client receives an e-mail in which a trial login URL to application software on the Web server is written and accesses the URL using the Web browser. It is shown. The trial login URL is composed of an address part and a parameter part for login access of the Web server.

  FIG. 2 is a diagram illustrating a configuration of a network processing apparatus of the entire Web system. A user who is a client can connect to a Web server using a Web browser and perform a desired operation.

  FIG. 3 shows a block diagram of the Web server side of the Web system. Reference numeral 301 denotes a system bus, and each of the internal devices 302 to 310 exchanges data through this system bus. Reference numeral 302 denotes a CPU, which performs login panel display processing and login processing according to the flowcharts of FIGS. A ROM 303 stores a fixed program necessary for starting up the OS of the system and accessing each device. A RAM 304 is used for reading a program obtained via the hard disk 305 or the network interface card 310 and temporarily storing data necessary for executing the program.

  A floppy (registered trademark) disk device 306 is used to read a program for causing a computer to execute the login process of this embodiment from a floppy (registered trademark) disk and to read and write other data. Reference numeral 307 denotes a keyboard and a mouse, and the user inputs instructions to the system via this input device. Reference numeral 308 indicates a system status on a display. A printer 309 can print operation log data on paper. A network interface card 310 exchanges data related to the login process and actual access process via the network cable 311.

  A method in which application software on the Web server accepts an access request from a user and sends login panel data will be described with reference to FIG. On the user side (client), when a URL received by e-mail or the like (the URL is composed of an access address and parameter information) is double-clicked, the URL is passed to the Web browser and is sent to the Web server. Will be accessing.

  In 401, the Web server application software receives a new request from the client. Specifically, it receives data according to the HTTP protocol sent from the client to the Web server, and analyzes the contents.

  In 402, it is determined whether or not the request is an address for login access to the Web server. If it is not correct, another application on this Web server processes this request.

  In 403, the parameter part is extracted from the request data, and if the parameter part is encrypted so that it is difficult for the user to understand, decryption is performed.

  In 404, the checksum data added to the parameter part is checked to confirm that the parameter part has not been altered or broken.

  At 405, it is confirmed whether the parameter is for login.

  If it is confirmed that the access request is for login, session information is newly created and stored in a predetermined location in the Web server in 406. Session information is stored on the server side as previous exchange information. If a request from a client is always sent with a session number, the previous exchange can be uniquely identified. It is a mechanism.

  In 407, additional information corresponding to the ID extracted from the parameter part is stored in the session information.

  In 408, data for displaying the login panel on the client side is created and sent to the client. At this time, the session number is also sent back.

  Next, since a login panel is displayed on the client side, when a response to this is input, the request is sent again to the Web server side. The login execution process will be described with reference to FIG.

  In 501, the Web server application software receives a new request from the client.

  In 502, it is determined whether or not the request is a response to the login panel.

  In 503, the parameter part is extracted from the request data, and if the parameter part is encrypted so that it is difficult for the user to understand, decryption is performed.

  In 504, it is verified whether the session information added to the request matches the information stored on the Web server.

  If the corresponding session information is stored on the Web server, it is determined in 505 whether the ID input by the user is the same as the ID stored in the session information. If they are the same, the user who entered the ID is recognized as a legitimate person, and the process proceeds to 507.

  If they are different, the login panel is created again at 506 and sent to the client to give an opportunity for re-input.

  In 507, authentication is executed with the original user name and password corresponding to the ID. In normal application software, operations that can be executed are limited by the user name.

  In step 508, information that has been authenticated by the specified user name is stored in the session information on the Web server, and subsequent access can be performed with the authority of this user.

  In 509, the operation screen of the Web application is created and transmitted to the client, and the client can operate the application on the Web browser.

  A method of performing login using the normal HTTP protocol and the function of the Web browser will be described with reference to FIG.

  In 601, the Web server application software receives a new request from the client. Specifically, it receives data according to the HTTP protocol sent from the client to the Web server, and analyzes the contents.

  In 602, it is determined whether the request is an address for login access of the Web server. If the destination is correct, the process proceeds to 603. If it is not correct, another application on this Web server processes this request.

  At 603, the parameter part is extracted from the request data. When the parameter part is encrypted so that it is difficult for the user to understand, decryption is performed.

  At 604, the checksum data added to the parameter part is checked to confirm that the parameter part has not been altered or broken.

  At 605, it is confirmed whether the parameter is for login.

  In 606, it is confirmed whether login information is included in the HTTP header. The web browser can embed a user name and a password in the HTTP header.

  If not entered, in 607, an access rejection response is returned to the client side.

  When the web browser receives an access refusal, a dialog for entering a user ID and password is displayed. When the user inputs and presses the confirmation button, the information is embedded in the HTTP header and the request is sent to the web server again. It has become.

  If login information is included in the HTTP header, the login information is decrypted at 608.

  At 609, the login information extracted from the parameter part is decrypted.

  At 610, it is confirmed that both login information is the same. If they are different, the process proceeds to 607, and an access rejection response is returned again.

  In 611, authentication is executed with the original user name and password corresponding to the login information. In normal application software, operations that can be executed are limited by the user name.

  In step 612, session information on the Web server is newly created, and the information that has been authenticated by the specified user name is stored. Subsequent access can be performed with this user's authority.

  In 613, the operation screen of the Web application is created and sent to the client, and the client can operate the application on the Web browser.

  As described above, according to the present invention, ID management work on the Web server side can be reduced and security can be enhanced.

The figure which showed operating a Web application using access request URL Diagram showing the overall configuration of the Web system Block diagram showing the configuration of this Web server The flowchart which shows the login panel display creation procedure of Example 1. The flowchart which shows the login execution procedure of Example 1 The flowchart which shows the login panel display and login execution procedure of Example 2

Explanation of symbols

301 System bus 302 CPU
303 ROM
304 RAM
305 HD
306 FD
307 Keyboard and mouse 308 Display 309 Printer 310 Network interface card 311 Network cable

Claims (4)

A reception step for receiving the URL requested to be accessed;
An extraction step of extracting additional information from the received URL;
A request step for requesting the client to input an ID;
A determination step of determining whether the ID sent from the client in response to the request in the request step matches the additional information extracted in the extraction step;
A log-in step for performing a log-in process when it is determined to match in the determination step;
A login processing method.   The additional information is composed of an ID and password pair, and in the determining step, it is determined whether the ID and password pair sent from the client matches the ID and password pair of the additional information. The login processing method according to claim 1, wherein: A reception step for receiving the URL requested to be accessed;
An extraction step of extracting additional information from the received URL;
A request step for requesting the client to input an ID;
A determination step of determining whether the ID sent from the client in response to the request in the request step matches the additional information extracted in the extraction step;
A log-in step for performing a log-in process when it is determined to match in the determination step;
A computer-executable log-in processing program comprising program code for causing a computer to execute each of the steps. Accepting means for accepting the URL requested to be accessed;
Extraction means for extracting additional information from the received URL;
Request means for requesting the client to input an ID;
A judging means for judging whether or not the ID sent from the client in response to the request from the requesting means matches the additional information extracted by the extracting means;
A log-in means for performing a log-in process when it is determined by the determination means to be matched;
A login processing apparatus comprising:

Images