Closed jkichline closed 6 years ago
The way I've solved this is instead of calling routes directly on the parse server that handle the authentication functionality, I've created cloud code functions (http://docs.parseplatform.org/cloudcode/guide/) to handle the authentication.
@jkichline sorry that we haven't addressed this. We're are moving on bringing the sdk back up to spec, albeit slowly at the moment. We won't be able to get to this immediately but I'll flag this so we can address it in good time. Priorities will be on presenting a new functional release, with patches included. There's no guarantee we'll get to this one in our first release, but we plan to be establishing a broader testing mechanism to account for issues that may arise due to platform variations. We'll keep you posted.
For future reference please report your issues in a more appropriate fashion. Venting your frustrations is fine, and pointing out flaws, problems or bugs is what we expect to make this better. However making claims of idiocracy is absolutely not a constructive means of addressing these issues. We expect everyone to conduct themselves appropriately regardless of what issues they may be experiencing. Please, keep this in mind while working with us and others.
Closing as it is stated that official ASP.NET support was never in place in the first in #121.
::edit:: We may consider adding in a disclaimer in our docs to prevent other users from running into this pitfall.
Thanks to some idiotic design, the Parse .NET framework DOES NOT function in ASP.NET properly. Instead of abiding by logic and security principals, the current user is stored as an machine-level property! This means that if you are planning to implement Parse on a web server, the last person to log in is the person's information that EVERYONE will see! This is such poor architecture of a framework, it's appalling.
We need this framework updated STAT to store the current user in SESSION on ASP.NET instead of in a file on the local machine. I can't believe that this is something that is not a) supported or b) clearly documented. It is a very expensive issue for us now since we are looking at redoing our entire website.
Please tell me I'm somehow wrong about this assessment, or provide a timeframe when we can expect true session support for ASP.NET (webforms and MVC) support.