Separate Security Configuration

[mostafakhudair]

Creates new Config\Security class and make \CodeIgniter\Security\Security class depends on it

removes useless properties
renames some methods and properties
add new public methods getHeaderName() & getCookieName()
edits changes in user guide

• Securely signed commits
• Component(s) with PHPdocs
• User guide updated
• Conforms to style guide

[paulbalandan]

While the move is good, we need to check for BC as removing properties from App config can be breaking for existing apps. Perhaps you can still persist it by supplying the values of the new Security config in the App constructor for the meantime, then hinting that these App config properties are deprecated in favor of Security config.

[mostafakhudair]

@paulbalandan could you tell me why Rector fails

[paulbalandan]

@paulbalandan could you tell me why Rector fails

Your docblocks should not use FQCN for classes. See the static analysis results for those docblocks.

[samsonasik]

@mostafakhudair while I appreciate your contribution, please don't change unrelated change (cosmetic changes) to the PR, like docblock and comment (That should be another specific pull request). It make harder to review, and harder to revert changes.

Also, please use meaningfull commit messages with specific task, better to squash them with group of task if they are steps,eg, the usecase for PR with title: "upgrade php requirement to 7.3 " can have the following commits steps:

• bump php requirement to 7.3
• remove reversed keyword/syntaxes in php 7.3

Until here, if there is no error, then stop. Improvement? Another pull request!

If above got error, eg: based on dependencies, eg: PHPUnit error, need upgrade to PHPUnit 9, then upgrade with new commit messages:

• upgrade requirement: phpunit 9
• update tests syntaxes to confirm with phpunit 9

No need to changes unrelated to the PR, really! So, that will be an easier to rollback in the future.

Thank you ;)

[mostafakhudair]

New clear PR under processing