User Tools
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
en:devel:corebosws:login [2020/06/10 15:32] gmoshi |
en:devel:corebosws:login [2021/04/27 18:20] (current) joebordes [More Information] |
||
|---|---|---|---|
| Line 3: | Line 3: | ||
| ===== Access to the System ===== | ===== Access to the System ===== | ||
| - | You need a valid vtiger CRM user to access the webservice. All the operations you can do through the REST interface will be limited by the vtiger CRM permission system of the connected user. | + | You need a valid coreBOS user to access the webservice. All the operations you can do through the REST interface will be limited by the coreBOS permission system of the connected user. |
| The REST API does not use the users password to connect. Instead it needs the user's access key which is a unique identifier created for each user that can be found in the user's preferences page. | The REST API does not use the users password to connect. Instead it needs the user's access key which is a unique identifier created for each user that can be found in the user's preferences page. | ||
| Line 9: | Line 9: | ||
| {{ :en:devel:corebosws:accesskey.png?800 |}} | {{ :en:devel:corebosws:accesskey.png?800 |}} | ||
| - | The login operation establishes a session between the REST client and the vtiger CRM application, validates the user and returns a session identifier which must be used in all subsequent calls to vtiger CRM. | + | The login operation establishes a session between the REST client and the coreBOS application, validates the user and returns a session identifier which must be used in all subsequent calls to coreBOS. |
| - | This login process is done in two steps, first we ask vtiger CRM for a challenge sequence and then we use the returned string to encode our access key for the final validation. | + | This login process is done in two steps, first we ask coreBOS for a challenge sequence and then we use the returned string to encode our access key for the final validation. |
| ==== Get Challenge ==== | ==== Get Challenge ==== | ||
| - | Our first code example will connect us to our vtiger CRM install and retrieve a challenge string which we need to accomplish the final login. This code will later be included in all our examples to establish the connection each time. | ||
| - | We include the necessary libraries: pear HTTP_Client, Zend JSON and an in house debugging class which will explicit all the communication going on if we need to see it. | ||
| - | All of our examples will accept one parameter called 'debugcall', if this variable is set to one (1) all the communication information will be printed on screen. | ||
| - | To get all this started you must point the $endpointurl to the location of your test vtiger CRM install and finally change the $userName if you are connecting as another user. | ||
| ^Purpose:|get a challenge string to encode the password for login| | ^Purpose:|get a challenge string to encode the password for login| | ||
| Line 32: | Line 28: | ||
| ====Login==== | ====Login==== | ||
| - | Now that we have the challenge token we can proceed with the login step. For this we have to send the **user name** and a **verification string**. This verification string can be constructed in two ways: | + | Now that we have the challenge token we can proceed with the login step. For this we have to send the user name and a verification string. This verification string can be constructed in two ways: |
| - | * as an md5 encrypted string of the challenge token plus the user's access key | + | |
| - | * as a the concatenation of the token string plus the user's password | + | |
| - | This operation is executed as POST. | + | *as an md5 encrypted string of the challenge token plus the user's access key |
| + | *as a concatenation of the token string plus the user's password <wrap em>this is insecure and NOT recommended</wrap> | ||
| + | |||
| + | This operation is executed as POST | ||
| ^Purpose:|Validate the user's access in the web service interface. The use of the getchallenge token is required| | ^Purpose:|Validate the user's access in the web service interface. The use of the getchallenge token is required| | ||
| Line 49: | Line 46: | ||
| }</code>| | }</code>| | ||
| ^URL Format:|<code>http://corebos_url/webservice.php?operation=login&username=[username]&accessKey=[accessKey]</code>| | ^URL Format:|<code>http://corebos_url/webservice.php?operation=login&username=[username]&accessKey=[accessKey]</code>| | ||
| - | ^Comments:|The accessKey parameter is written with a capital 'K'\\ The user's access key can be found o nthe user's profile screen inside the application| | + | ^Comments:|The accessKey parameter is written with a capital 'K'\\ The user's access key can be found on the user's profile screen inside the application| |
| - | Once these two steps have been taken we can continue by calling any of the webservice functions. | ||
| + | Once these two steps have been taken we can continue by calling any of the web service functions. | ||
| + | ====Logout==== | ||
| - | ====More Information==== | + | ^Method:|logout| |
| + | ^Purpose:|The logout service eliminates the session information, invalidating any further operations with that session ID. For security reasons this method should be called when the user of the external application finishes his tasks. He should have an option to close the application.| | ||
| + | ^Profile:|logout(sessionId:string):Map| | ||
| + | ^Send as:|POST| | ||
| + | ^Parameters:| => sessionId: session ID to invalidate.| | ||
| + | ^Response:|map with one entry: successfull| | ||
| - | * This method of authentication is called Challenge-Handshake Authentication Protocol and it is more secure than a username/password authentication. [[https://tools.ietf.org/html/rfc1994|Read here for more information]] | ||
| + | ====More Information==== | ||
| + | |||
| + | * This method of authentication is called Challenge-Handshake Authentication Protocol and it is more secure than a username/password authentication. [[https://tools.ietf.org/html/rfc1994|Read here for more information]] | ||
| + | * [[en:devel:corebosws:methodreference#crud_users|Read here for methods on how to change the user password and/or access key]] | ||
| + | ---- | ||
| + | <WRAP right> | ||
| + | [[:en:devel:corebosws:querylanguage|Next: Query language]] | [[en:devel:corebosws:tableofcontents|Table of Contents]] | ||
| + | </WRAP> | ||
| + | ---- | ||
