I have been searching a lot for info and examples of the principles of making a simple multi-user web application.
The app i am going to make is used for deadline management and can be described as a simple calendar where users can register events.
I have no problem making this for a single user in PHP or ASP.NET, but how can i make this for multiple users, so they can register and only see their own data.
The app itself is pretty simple, and there will not be many users max. 50-100.
I find it hard to find info about this topic.
My own idea, which probably isn't the right way to do it is:
When a user creates an event, store it in a table with the user's ID.
When selecting data, use the logged in user's ID and get the corresponding event(s).
I would strongly recommend working within a framework in order to avoid re-inventing the wheel. If you know python, consider flask, pylons, or Django. If you would prefer to continue working in PHP (you should avoid working with ASP.NET if you are ever going to work with non-Windows developers) try Drupal. Ruby on RAILs has some options, as well, but I've never used it.
The way you are attempting to implement this is likely to lead to an oversized, overcomplicated database that is very hard for new developers to get used to. If you must implement this yourself, you should have a user/password table, an events table, and a table linking together the two (e.g assigning ownership).
Related
I have a Firestore collection that I need to rename.
To do that I'll have to do two things. One, rename the collection, two, update my app (only web right now) to use the new collection name.
My problem is that if I just go ahead and do that, any user that has not refreshed the app won't be able to find the renamed collection.
So, my question is: Is there any best practice to handle this scenario?
I can think of a couple of options:
Somehow forcing a reload of the web apps immediately after renaming the collection.
Set a feature flag so that the web apps enter into maintenance mode while I update everything and then reload the web apps once the change is finished. Unfortunately the currently deployed web app doesn't have a maintenance mode to enable so this doesn't seem to be a valid solution.
However, I'd like to hear about other options. There might be some best practice that I'm missing. Moreover, I'm aware this is a problem that might be more general than just related to Firestore. For example when changing a REST API endpoint, so I guess there must be some tried and tested solutions out there.
I tried searching for best practices regarding this and couldn't find any.
Also, if I was consuming a REST API it would be easier to solve because I could change the DB and keep the DB unchanged. But given that Firestore gets consumed directly from the web app I don't have this benefit.
Locking out outdated clients is a common practice, but leads to a lesser user experience. It also requires that you have a mechanism for the clients to detect that they're outdated, which you don't seem to have.
The most common practice I know of is to perform dual writes to both the old and the new collection while clients are updating.
Hi ive asked this over on the offical asp.net forums aswell though it would hurt to ask here to.
First some background information (feel free to skip it)
i've only recently started learning asp.net web pages
To start i picked up a few books, that went through web security register/login etc. Using the WebSecurity class.
A while back I made my own website to sell/distribute my own software. This was done using php & mysql.
However ive been wanting to update this as well as build a few more product oriented websites. And just use the main site as a store.
I could do this in php but I would need to brush up on it first. Which given my situation isn’t the best use of my time. As lots of jobs ask for experience using asp.net as well as several years programming experience part of the reason I decided to try and develop my own software. But it it doesn’t work out ill need a job which is why I started learning asp.net.
Now the problem
For my existing site I chose to generate a string of random letters and numbers to use as ids for products, customers etc. I do the same in my software as well instead of using the auto increment in the data field so id 1,2,3 etc.
instead I have strings like a3hgt4ssf, 3243dfsa, sdas342d.
Initially things started okay using following the book using WebSecurity and along with the role provider to deal with logins, creating users, restricting access etc.
Then I found out I had to use the auto incrementing ids. So I started creating my own web security and role provider based upon theirs same functions etc.
But now im stuck initially I stored some data in cookies loggedIn, customerid, username no password then I just checked for the is login cookie. This was how the books did it when I first started learning web development but I moved to software and haven’t followed it to much over the years (lack of time).
Now im not sure if I should be using cookies (same as before) or not, or should I use sessions which expire when the browser closes (as far as I know)
My main concern being security i'm using paypal to process payments. So I think that makes it less of an issue but still.
Im also aware of the size of the .net framework, so I don’t want to reinvent the wheel if features are already available to the accomplish what I need.
We’re currently evaluating development with Sitecore 6 for a project. The client already bought it, so using another CMS isn't an option. The proposed setup would have Sitecore as our site’s content data provider; which would be consumed by a site built in ASP.Net MVC 3. We’d use Sitecore’s libraries to retrieve data from the Sitecore database on the server side.
In some cases, we also may want to consume content data via client side AJAX calls. I’ve been working on prototypes for this to see what data I can get back from a custom proxy service. This service calls GetOuterXml on the item, converts the Xml to JSON, and sends back the JSON to the calling script. So far, I’m finding using this method limiting; as it appears GetOuterXml only returns fields and values for fields that were set on the specific item, ignoring the template’s standard value fields and their default values for example. I tried Item.Fields.ReadAll(), still wouldn’t return the standard values. Also, there are circular references in the Item graph (item.Fields[0].Item.Fields[0]...); which has made serialization quite difficult without having to write something totally custom.
Needless to say, I've been running into many roadblocks on my path down this particular road and am definitely leaning toward doing things the Sitecore way. However, my team really wants to use MVC for this project; so before I push back on this, I feel its my responsibility to do some due diligence and reach out to the community to see if anyone else has tried this.
So my question is, as a Sitecore developer, have you ever used Sitecore as purely a content data provider on the client-side and/or server-side? If you have, have you encountered similar issues and were you able to resolve them? I know by using Sitecore in this way; you lose a lot of features such as content routing/aliasing, OMS, the rendering and layout engine; among other features. I’m not saying we’re definitely going down this path, we’re just at the R&D phase of using Sitecore and determining how it would best be utilized by our team and our development practices. Any constructive input is greatly appreciated.
Cheers,
Frank
I don't have experience with trying to use Sitecore solely as a data provider, but my first reaction to what you're suggesting is DON'T!
Sitecore offers extremely rich functionality which is directly integrated into ASP.Net and configured from within the Sitecore UI. Stripping that off and rebuilding it in MVC is lnot so much reinventing the wheel as reinventing the car.
I think that in 6.4 you can use some MVC alongside Sitecore, so you may be able to provide a sop to your colleagues with that.
I just discovered ASP.net uses its own profile system to register users and there seems to be a lot of features available as bonus with it (such as secure authentication). However it seems rather specific to have such a feature for a general purpose development environment and things which work in the background the way the profiles system does without me really knowing how (like where the user data is stored) kind of scares me.
Is it worth developing a website which requires user authentication using the asp.net profile system or would it be better to develop my own using SQL databases and such? I'm not going to avoid using SQL anyway, even if I use profiles I'll use the profiles unique ID to identify user data in the SQL table so in that sense I'm not going to avoid using SQL for user information at all.
My favorite thing about profiles is that you can create custom permissions in Web.config files using them () and avoid having to type in the same code to the top of all your aspx source files to do the authentication check.
The other thing I kind of like about it is that security is built in with secure authentication cookies, so I wouldn't have to deal with them myself.
But it doesn't seem like that big of a deal really. I'm just confused as to where profiles stand as far as ASP.Net development goes and what they're designed to accomplish.
The Profile/Membership and Role provider API is very intertwined, and specifies things very narrowly. The benefit is that there is little you have to do to get a lot of functionality working. The disadvantage is when what you need doesn't match what is provided. Nevertheless, there are many potential gotcha's that the API takes care of for you that it really does make sense to use it, at least for authentication.
My needs did not match what the API provided, and I really only needed the Membership portion. The problem is that I had a piece where I needed to use the same authentication and authorization across a web application and a desktop application. My needs are pretty unique, but it's designed for a classroom setting.
Getting the membership to work for my needs wasn't that difficult. I just had to implement the Membership API. There are several features I just didn't need with the Membership API like self-registration, etc. Of course this did present me with a challenge for role management. Typically, as long as your user object implements IPrinciple it can be used directly--but there are serialization issues with the development web server Visual Studio packages if your user class is not defined in the same assembly. Those problems deal with serialization, and your choices include putting the object in the GAC or handle cross-appdomain serialization yourself with objects that are in the GAC like GenericPrincipal and GenericIdentity. That latter option is what I had to do.
Bottom line is that if you don't mind letting the API do all the management for you, than it will work just fine. It is a bit of smart engineering work, and attempts to force you down a route with decent security practices. I've worked with a number of different authentication/authorization APIs (most were not CLR based), and the API does feel a bit constraining. However, if you want to avoid pitfalls with session/state/cache management you really need to use the API and plug in your own providers as necessary.
With your database, if you need to link a user with any database element you'll be storing the user's login id (Context.User.Identity.Name).
You seem to mix the Profile/Membership/Role provider API. But to answer your question: why not use it? I would use it unless there is a real constraint that makes it unusable...
When my user registers in Drupal and his account is created, I'd like to be able to create an account in a 3rd-party system (e.g. some moodle site).
Is that possible with an existing module? If not, what would be the preferred way to add this functionality?
You'll need to create a new custom module and implement the hook_user().
Specifically, you'll need to support the 'insert' operation, but of course you could add support for many others (such as delete or update) so you can manage users from your Drupal installation as well.
BTW: no existing module will couple exactly with your system, unless you're referring to a 3rd party application - in which case it'd help if you could tell us which one you're using :)
I second Sebs suggestion of using hook_user() for this, either after the fact on the 'insert' action, or upfront on 'validate', or on both, depending on how you need to deal with an eventual failure of Drupal itself or the 3rd-party-system.
Also, given your other question in this context, it looks like you might be interested in the following posts/discussions concerning external authentication in general:
Distributed Authentication changes (A short note/description of changes compared to Drupal-5)
Refactor distributed auth out of user.module (lengthy but informative discussion leading to the current state of things)
External Authentication in Druapl 6 (Some user experiences with the current state)
You might also want to take a look at the OpenID integration in Drupal core as a somewhat 'authoritative' source of examples.
You might also check out the Moodle module for Drupal. I used it a couple years ago and it was kind of a headache, but I'd guess that it's come a long way since then.
Interestingly, they recommend using OpenID to manage users between the sites. That may be easier than implementing your own hook_user instance if you aren't very comfortable writing Drupal modules. Just a thought.