u/pc/rhodecode-enterprise-ce-fork-pc Files · docs/contributing/api.rst

auth: don't break hashing in case of user with empty password....

auth: don't break hashing in case of user with empty password. In some cases such as LDAP user created via external scripts users might set the passwords to empty. The hashing uses the md5(password_hash) to store reference to detect password changes and forbid using the same password. In case of pure LDAP users this is not valid, and we shouldn't raise Errors in such case. This change makes it work for empty passwords now.

marcink - - Load All Authors

File last commit:

r1120:d4155363 default


                r2203:8a18c3c3

default

Download file

             api.rst
        
                    60 lines
            
             | 1.2 KiB
            
                | text/x-rst
            
             |
                RstLexer
            
             / docs / contributing / api.rst
          
                    History
                
                 |
                  Source
                 | Raw
                 |Copy content
                 |Copy permalink

        marcink
    
project: added all source files and assets

              r1
            
        marcink
    
docs: fixed small wanrings/errors during build.

              r1120
            
      ===================

      CONTRIBUTING TO API

      ===================

        marcink
    
project: added all source files and assets

              r1
            
      Naming conventions

      ==================

      We keep the calls in the form ``{verb}_{noun}``.

      Change and Deprecation

      ======================

      API deprecation is documented in the section :ref:`deprecated` together with

      other notes about deprecated parts of the application.

      Deprecated API calls

      --------------------

      - Make sure to add them into the section :ref:`deprecated`.

      - Use `deprecated` inside of the call docstring to make our users aware of the

        deprecation::

          .. deprecated:: 1.2.3

             Use `new_call_name` instead to fetch this information.

      - Make sure to log on level `logging.WARNING` a message that the API call or

        specific parameters are deprecated.

      - If possible return deprecation information inside of the result from the API

        call. Use the attribute `_warning_` to contain a message.

      Changed API calls

      -----------------

      - If the change is significant, consider to use `versionchanged` in the

        docstring::

          .. versionchanged:: 1.2.3

             Optional explanation if reasonable.

      Added API calls

      ---------------

      - Use `versionadded` to document since which version this API call is

        available::

          .. versionadded:: 1.2.3

             Optional explanation if reasonable.

	Site-wide shortcuts
/	Use quick search box
g h	Goto home page
g g	Goto my private gists page
g G	Goto my public gists page
g 0-9	Goto bookmarked items from 0-9
n r	New repository page
n g	New gist page

	Repositories
g s	Goto summary page
g c	Goto changelog page
g f	Goto files page
g F	Goto files page with file search activated
g p	Goto pull requests page
g o	Goto repository settings
g O	Goto repository access permissions settings
t s	Toggle sidebar on some pages

marcink project: added all source files and assets	r1
marcink docs: fixed small wanrings/errors during build.	r1120	===================
		CONTRIBUTING TO API
		===================
marcink project: added all source files and assets	r1


		Naming conventions
		==================

		We keep the calls in the form ``{verb}_{noun}``.



		Change and Deprecation
		======================

		API deprecation is documented in the section :ref:`deprecated` together with
		other notes about deprecated parts of the application.


		Deprecated API calls
		--------------------

		- Make sure to add them into the section :ref:`deprecated`.

		- Use `deprecated` inside of the call docstring to make our users aware of the
		deprecation::

		.. deprecated:: 1.2.3

		Use `new_call_name` instead to fetch this information.

		- Make sure to log on level `logging.WARNING` a message that the API call or
		specific parameters are deprecated.

		- If possible return deprecation information inside of the result from the API
		call. Use the attribute `_warning_` to contain a message.


		Changed API calls
		-----------------

		- If the change is significant, consider to use `versionchanged` in the
		docstring::

		.. versionchanged:: 1.2.3

		Optional explanation if reasonable.


		Added API calls
		---------------

		- Use `versionadded` to document since which version this API call is
		available::

		.. versionadded:: 1.2.3

		Optional explanation if reasonable.