chore(dev): Add Sessions Requirements

[yezz123]

A Redis-based session backend for the Fastapi applications

from typing import Any

from fastapi import Depends, FastAPI, Request, Response

from authx.core import deleteSession, getSession, getSessionId, getSessionStorage, setSession, SessionStorage

app = FastAPI(title=__name__)


@app.post("/setSession")
async def _setSession(
    request: Request, response: Response, sessionStorage: SessionStorage = Depends(getSessionStorage)
):
    sessionData = await request.json()
    setSession(response, sessionData, sessionStorage)


@app.get("/getSession")
async def _setSession(session: Any = Depends(getSession)):
    return session


@app.post("/deleteSession")
async def _deleteSession(
    sessionId: str = Depends(getSessionId), sessionStorage: SessionStorage = Depends(getSessionStorage)
):
    deleteSession(sessionId, sessionStorage)
    return None

Config

Deafult Config

• url of Redis: redis://localhost:6379/0
• name of sessionId: ssid
• generator function of sessionId: lambda :uuid.uuid4().hex
• expire time of session in redis: 6 hours

Custom Config

from authx.cache import basicConfig

basicConfig(
    redisURL="redis://localhost:6379/1",
    sessionIdName="sessionId",
    sessionIdGenerator=lambda: str(random.randint(1000, 9999)),
    expireTime=timedelta(days=1),
    )

[codecov]

Codecov Report

Merging #207 (24c37f2) into main (e021ce4) will increase coverage by 0.57%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #207      +/-   ##
==========================================
+ Coverage   93.01%   93.59%   +0.57%     
==========================================
  Files          37       41       +4     
  Lines        1332     1452     +120     
==========================================
+ Hits         1239     1359     +120     
  Misses         93       93              

Impacted Files	Coverage Δ
tests/middleware/test_middleware_Oauth2.py	100.00% <ø> (ø)
authx/core/__init__.py	100.00% <100.00%> (ø)
authx/core/session.py	100.00% <100.00%> (ø)
tests/cache/test_cache_config.py	100.00% <100.00%> (ø)
tests/core/test_core_deps_session.py	100.00% <100.00%> (ø)
tests/core/test_core_session.py	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e021ce4...24c37f2. Read the comment docs.

[pull-request-quantifier-deprecated]

This PR has 390 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

---

Quantification details

Label      : Large
Size       : +384 -6
Percentile : 79%

Total files changed: 16

Change summary by file extension:
.py : +246 -2
.dockerignore : +90 -0
.env : +3 -0
.yml : +12 -0
.txt : +0 -0
.toml : +3 -0
Makefile : +0 -4
example/session/Dockerfile : +13 -0
example/session/Makefile : +17 -0

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

• Fast and predictable releases to production:
  • Optimal size changes are more likely to be reviewed faster with fewer
    iterations.
  • Similarity in low PR complexity drives similar review times.
• Review quality is likely higher as complexity is lower:
  • Bugs are more likely to be detected.
  • Code inconsistencies are more likely to be detetcted.
• Knowledge sharing is improved within the participants:
  • Small portions can be assimilated better.
• Better engineering practices are exercised:
  • Solving big problems by dividing them in well contained, smaller problems.
  • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

• Use the PullRequestQuantifier to quantify your PR accurately
  • Create a context profile for your repo using the context generator
  • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
  • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
  • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
• Change your engineering behaviors
  • For PRs that fall outside of the desired spectrum, review the details and check if:
    • Your PR could be split in smaller, self-contained PRs instead
    • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

• One line was added: +1 -0
• One line was deleted: +0 -1
• One line was modified: +1 -1 (git diff doesn't know about modified, it will
  interpret that line like one addition plus one deletion)
• Change percentiles: Change characteristics (addition, deletion, modification)
  of this PR in relation to all other PRs within the repository.

---

Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

[sourcery-ai]

Sourcery Code Quality Report

❌  Merging this PR will decrease code quality in the affected files by 5.01%.

Quality metrics	Before	After	Change
Complexity	0.00 ⭐	0.00 ⭐	0.00
Method Length	10.00 ⭐	18.00 ⭐	8.00 👎
Working memory	1.00 ⭐	3.50 ⭐	2.50 👎
Quality	99.75% ⭐	94.74% ⭐	-5.01% 👎

Other metrics	Before	After	Change
Lines	8	27	19

Changed files	Quality Before	Quality After	Quality Change
authx/cache/init.py	100.00% ⭐	100.00% ⭐	0.00%
authx/core/init.py	99.50% ⭐	89.49% ⭐	-10.01% 👎

Here are some functions in these files that still need a tune-up:

File	Function	Complexity	Length	Working Memory	Quality	Recommendation

Legend and Explanation

The emojis denote the absolute quality of the code:

• ⭐ excellent
• 🙂 good
• 😞 poor
• ⛔ very poor

The 👍 and 👎 indicate whether the quality has improved or gotten worse with this pull request.

---

Please see our documentation here for details on how these metrics are calculated.

We are actively working on this report - lots more documentation and extra metrics to come!

Help us improve this quality report!