Is there any way a c# server can store Sessions for web without developing the web in asp.net?
We have this web in angular and I want to improve performance of our server and I have 2 ways:
make some caching in the server with a singleton which store data
store sessions
Problem with 1 is that there are too many locks in code which im affried will cause a bottleneck (such as User log in, insert him to a "logged users" list for future locks on the user object).
So 2 will probably works best, but, is there anyway to build such thing? I can seem to find any reference to such thing without using the asp.net web.
Comminucation in web is done via AJAX request so I think, perhaps im wrong, that I can't maintain a TCP connection with the web so Reactor type server cannot help me.
TIA.
Maybe StateServer will solve your issue. You can store sessions via StateServer service in another server. Then you can manage it easily.
Related
I am migrating the my old ASP.NET Web Forms project to ASP.NET Core Web API and Frontend Angular. in my older application storing user information instace and it's values(like assigned groups,permissions,and other user information).i am going to use JWT i can't store all information in JWT,so should i continue session in my asp.net core application or retrieve this information from database in each request?
Is there any other Best practices are available in modern application development?
Multiple options for this, depending on what you need:
Angular cache. If the data is not sensitive, you can use the rxjs observables to cache some data on the application side. Nothing wrong with some data stored on the browser. Since you are coming from a full postback application, the SPA caching is most times equivalent to old Session object.
Depending on the implementation you might need some cache on the server side too. Since as mentioned you'll have multiple servers, I'd suggest only caching lookups and such, not user related data. If you implement stickyness with servers and sessions (not recommended), this is still an option.
Distributed cache. You might have heard of Redis and such? This is also an option to store cache data to a third service, accessible by all server instances.
It all comes down to complexity vs speed. If the queries are simple enough and lightning fast, then it might be useless to store them in any cache anyway.
I want to create a game within the Unity game engine in C# with .NET where I can securely connect out to a private server, and read and write data from/to the server. I understand how to do this in a non-secure way, where I would setup a private SQL database with a webpage interface between the two.
My problem comes here, I know if I want the web interface to be public, I need credentials to connect to the server, such as an Auth key, or username and password. However, in order to use those, then the auth-key would need to ship with the game as a file, or would need to be written directly into the codebase. I know that users can decompile games, and access these files and get the credentials if I include them, which means that option is off the table as far as I am aware.
It is my understanding that even with this layer between the database and the client, someone could still find the url for the interface between them, and then send custom function calls to this url as I will be doing in the game program. Wouldn't this lead to the same conclusion as having the database be open?
If anyone has answers to this, or resources where I can learn about this process, please let me know! I have never done server-side programming before and have also never thought about security before in my life.
You're correct in that you should not embed authentication keys into your apps. Where you're falling down is in exposing your database to the world. Don't do this. Instead, hide it behind a web server that serves only json data files. This way you can take advantage of the web server's authentication and session protocols.
Since you're already working with C#, I would suggest looking into ASP.NET Core MVC and specifically about WebAPI. But I would probably recommend node.js for lightweight microservices.
I have a server on the WebApi2, and I need get all active users on the server.
How to implement it?
I think, maybe, save customerId after logIn in the session storage.
But I don't know how to implement it.
Or maybe exists some best solutions for it.
Help me please, with this issue.
You can access session object using this kind of code.
Keep in mind that Web API provides REST services, and is from a design perpective not meant to access Session objects, as its purpose is to provide stateless methods.
This of course does not mean it is not technically feasible, as you can see on this SO answer.
Use this article Adding Session support to ASP.NET Web API for example
as the entering point to find out the best solution.
I am currently building an authentication server for a game. Basically how I have it planned out is a client will connect to our servers and they will authenticate the client and then issue the client a ticket. As long as the ticket is valid the client is able to join servers. Besides authentication I would like to display user stats and other stuff on their profile. I have not done anything with ASP.NET before but I think that is the right way to go on this. I was wondering if anyone knows where I might get started with communication with an ASP.NET web app. Is that too big of a step since I haven't used ASP.NET before? Should I start with something smaller?
EDIT:
Ok so I have a simple WCF Service now but I am having trouble understanding exactly how to use it. How do I actually use the service I created to exchange data between a console app and a ASP web site? Anyone know of a tutorial that creates a WCF service then actually shows how to implement it into a project?
Another option is to use someone else authentication server. I.e. Facebook, Messenger (Live.com), Google all provide OAuth authentication if you can agree to use their list of users.
Side benefit is that you don't need to worry a bit less about personal information (i.e. child accounts require much more care that you want :) ).
What kind of game? Is it a game played on your website or a client application? If it's a website then all you really need is a Login page. Otherwise, yeah WCF.
Our application is well structured (well we did our best!) and we have split the Model from the View, Now, we need to let some information to our client with a web access. We would like to build something small with IIS and some webform.
Here some information you might think are useful:
Our controller have Thread of database queries
Our database is PostGresql
All is build with C#2.0
We used a lot of databinding between our View and Controller in Winform.
Winform will stay for internal purpose, only a small part will be available on the Internet.
What are your suggestions for this kind of move?
Update
We will host the web in our company server so the database will stay inside the business. No need to duplicate data or any synchronization.
I think the "synchronizing" Michael is talking about is the data in the database and the view presented by the Winform app.
We had a similar problem, and the solution we came up with is to create a Web service that exposes the data via XML and use the service from both the web app and Winform app. Every time you update data send it to the web service, and every time you perform a query get the latest data from the service. Do not consider caching data on the Winform app unless you have profile data showing it is a bottleneck, or you want to run unconnected from the network.
This is perfectly possible in .Net 2, you do not need 3.0 or WCF.
The biggest challenge is going to be synchronizing your database between the local Winforms application and the hosted Webforms application. Once you do that, creating the web app is easy.
If your web application is read only, then you can set up replication. Find a tool that you like. Three that I found through a quick search are:
Slony-I
Mamoth Replicator
Bucardo
If your web application is not read only, then the problem is more difficult. You might want to consider upgrading to .NET 3.0 or 3.5 so you can use WCF. If there is a significant overlap in functionality, you might want to move your data to the web exclusively and expose it through WCF services.