mirror of
https://github.com/cypht-org/cypht.git
synced 2026-04-25 04:56:03 +03:00
[GH-ISSUE #259] New Session Storage loop ? #220
Labels
No labels
2fa
I18N
PGP
Security
Security
account
advanced_search
advanced_search
announcement
api_login
authentication
awaiting feedback
blocker
bug
bug
bug
calendar
config
contacts
core
core
devops
docker
docs
duplicate
dynamic_login
enhancement
epic
feature
feeds
framework
github
github
gmail_contacts
good first issue
help wanted
history
history
imap
imap_folders
inline_message
installation
keyboard_shortcuts
keyboard_shortcuts
ldap_contacts
mobile
need-ssh-access
new module set
nux
pop3
profiles
pull-request
question
refactor
release
research
saved_searches
smtp
strategic
tags
tests
themes
website
wordpress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/cypht#220
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Yamakasi on GitHub (Feb 8, 2018).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/259
Is it with a reason that first the cookie is placed and the session is stored with an empty array which is checked as "arrray" and after that the cookie/session is "checked/seen" where after the data is stored into the session and grabbed back ?
I feels like a loop which is not needed. Setting the cookie, then paste data in the sessionstorage at the same time will do the same checks and can fail whenever your want.
If so I can optimize this a little bit as the session handler is a little but messy.
@jasonmunro commented on GitHub (Feb 8, 2018):
I don't know what code you are describing and I am not interested in refactoring core session code at this time.
@Yamakasi commented on GitHub (Feb 8, 2018):
The db_start part is actually mostly involved. I have discussed this with some devs and the empty array is not ideal and can even be a security issue to get a login without any userdata but still.
It's not really core, as you are extending the classes all over the place and reusing unrelated functions you also need to use in the site module this could be done much better with some small replacing of functions in the right classes.
If the security concerns you the core should be always under review and not closing issues with no interest.
@jasonmunro commented on GitHub (Feb 8, 2018):
After more than a year of helping you with Cypht, I have run out of patience. You consistently ignore what I have to say, claim that you know better than I do on everything (even when you are woefully uninformed), and insult both me and the project on a regular basis.
I simply can't take it anymore.
Even in your reply above you are saying that the design choices in Cypht are bad, and you could do better. Please do! I implore you to write your own webmail project as it will surely be far superior.
If you want to continue to be a part of the Cypht community, you need to re-evaluate how you communicate on IRC and Github. I'm well aware that the Cypht code is not perfect. Telling me about how much better your choices would be, without ever actually contributing anything but criticism, is not helpful.
I'm tired of trying to explain my reasoning when you don't actually listen to it. So please, show some respect for the project, find another webmail system to use, or write your own.
@Yamakasi commented on GitHub (Feb 9, 2018):
I don't understand your opinion and dissociate myself from it, you seem to have difficulties it seems, maybe because of your on IRC public made illness momentary ?
I don't use Cypht for over a year, I'm busy with it about 6 months from time to time and that raises up questions and opinions you need to be capable of to take in the public FOSS community.
If you want to Cypht be a success you might want to accept more opinions and community help as you did in the past. The additional features have been great so far, I have never discussed them but on my way crawling code, let others reviews some parts it raises questions and some are very valid, some a just a (bad) decision in design and can be discussed and fixed by the community if you allow it.
As you speak about "we" now mostly in all your response and you are the only committer I lost track there, but let's hope you keep up the good work and don' t let it endup like Hastymail, Cypht is much better.
Take care.
@jasonmunro commented on GitHub (Feb 9, 2018):
Maybe you are right, it might have only been six months. You telling me "You are doing it wrong" on a regular basis makes it seem like a LOT longer.
I want to point out one more time that I have been very accommodating to your requests, and have gone out of my way to be patient and helpful, and up until now, have ignored the way you talk down to me.
Yet you still talk to me like I'm an idiot who does not know what he is doing. Please stop doing this! Running an open source project does not mean I am obligated to be insulted by anyone who feels like it.
Just because you don't understand some code does not make it bad or wrong. Just because you would do it differently does not make it bad or wrong. Just because Cypht does not work the way you want it to does not make it bad or wrong.
I'm asking you to be considerate and constructive with your feedback. I'm asking you to consider that you might not know everything, and that maybe there is a good reason why something is the way it is that you are not aware of.
@Yamakasi commented on GitHub (Feb 9, 2018):
That is why critism exists, also in FOSS projects.
Just don't take it so hard when people say, this is wrong. At the end it could be OK but not complete OK. That is why there is changes on the go and refactoring all the time. But with good criticism and reviewing all the time you can make that happening less. No criticism, no good progress, and that is the goal.
See my comment at #258 consider that and rip it apart otherwise you are mixing base functions with extensions where you never can decide what is the base actually, someone wants this or that. If you make that modular it's much easier to maintain, makes the code much more slick and saves you a lot of fixes in the future.
And indeed, that is why such things will be a huge refactor and I overthink such stuff always a lot as refactoring things that is not needed is always a waste and we need to try to avoid that if you start extending Cypht with a some extension like that.
Let's cut the crap and make this project more of a success!
@jasonmunro commented on GitHub (Feb 10, 2018):
If you want me to take your criticism of Cypht seriously, then take the time to learn its architecture. Glancing at the session code and deciding "there is too much inheritance" is not good criticism.
Cypht has a unique design. If you want to provide valid feedback, you need to learn how the program works. Instead you are throwing out generic software design principles that you don't seem to understand.
Your comment on issue 258 makes no sense. I'm not talking about mixing base functions with extensions. I'm talking about building a module set that could be used as the basis for a new data source, making the development of a new module set for JMAP or EWS much easier to implement. Module sets are how Cypht creates an abstraction layer between features and the core framework. The framework is the "base", and module sets are the "extensions". If you tried to understand how Cypht works you would have figured that out.
I have invested thousands of hours into this project. So yes, I will be offended when someone with no understanding of the way it works or the reasoning behind it tells me "X code is bad" or "Cypht should be like X".
This is a pointless discussion. Please try to back up your criticism with specific facts. Please try to respect the effort that went into this project.