I am new to web development but I have some experience in VB.Net desktop app programming. The software I am currently maintaining is only accessible within the company office network. Now that the management demanded the software to be accessible online, I have no choice but to convert it as a web-based system.
I had already started developing the software using laravel framework and so far so good. I successfully created the login form, few pages with CRUD implementation.
However, I came to a confusing part of development stage where I want to prevent some type of users from editing/adding/deleting records. Basically, there are two type of users I'm using which are Administrator and Normal User.
I already made many sections and pages, and I'm thinking of creating a duplicate version of these pages and folders for normal users only. This way I can remove some of the edit/delete/etc from the pages that are not needed for the user. But I'm still in dilemma because if I create duplicates for these pages, it would be tiresome to make changes in future when maintaining it.
So, what do you guys think? should I make a modified copy of the pages or just use the same pages for all users and disable some features based on user type?
Related
Since we currently maintain 6 applications that were developed with Laravel, the wish has now arisen that there is a unified login system.
Currently we are working with a database purely for authentication where all applications access it. So the user only has to be created once for all 6 applications.
Now I would like the user to have only one login page and be able to use all applications after authentication.
I would solve the problem with a RSYNC task which synchronizes the cache of the applications. However, I think that there is a better way, so I ask you
What you are looking for is called a Single sign-on, which has been answered here before some times, but for people who don't know how to call it, it would be pretty hard to find! So here are some links:
Good single sign-on solution for Laravel by lesssuger
single sign on (sso) laravel by Moauya Meghari
I have a certain requirement where i will have a central laravel application, and it has all the users in there. Then there are 2-3 sub laravel applications. The users are individually given access to these sub applications.
Now the requirement is that these sub applications shouldn't have any users in there. They should query the central laravel application (through api).
So if someone signs in the central laravel application, it should automatically sign-in to the other applications that they are given access to.
I am aware that providing code wont be possible, so just an overall overview of how it might work and some packages that might be helpful would be really great. Thanks in advance.
I have pretty much done this. I really struggled to find examples/advice so just started building it.
I have several applications, all for internal use.
I have one application/db for storing users/roles/permissions.
In my other applications, the user model just points to the usermanager db.
When user log in, I grab all their permissions for this application and store them in the session.
Seems to be working so far.
Mick
Say that I have two or more completely separate web applications. The might even be running on a different server and use different language & framework.
What I need to do is to share state, or at least authentication. For example if the user logs in on one of the websites and goes to another one, he will be able to authenticate using his credentials from the first website.
For example, if I have one website running e-commerce and another one is a blog, I want all the e-commerce users be able to comment on the blog with the information from their profile.
What is the best way to do this? Is it even a good idea?
The only solution that comes to my mind is abstracting away the profiles and authentication and create some kind of global profile and then use that on both of those websites. But that seems like a really complex solution considering what I need to achieve.
OpenID seems like a good way.
I am wondering what the best way is to share authentication, session management, etc. across a web site with both a mobile and desktop version. We are running Tomcat, and prefer to keep the mobile and the desktop sites separate applications on separate nodes.
I have seen similar posts regarding persisting the session throughout Tomcat applications, but I'd prefer to do this through the app alone. I've read about clustering in Tomcat, but that appears to be for a single app running across many nodes.
Is there a common way to do this? How do other sites handle session management across mobile and desktop versions?
if I understand correctly you are implementing you mobile and desktop versions of your site as separate web applications. Sharing sessions across multiple apps is not part of the j2ee specs as far as I know; in addition to that I am not aware of any product that offers the functionality..
..So, that would leave you with the option of implementing your own :)
one obvious approach would be to use the db to store session data instead of HttpSession; I'm not saying this is easy; actually may be a good reason to reconsider the decision of having two separate apps for the same site
I have a desktop application which uses flat files (some xml and small pictures) as data. I want this data to be available on other PCs which have the desktop application installed and usable by a smartphone client (WP7 at the moment) as well.
The user should have it very easy to synchronize this data. He should be able to use accounts he already possesses (Live-Login, Googlemail, Facebook,...).
I thought about using Azure Blob Storage to save the data in Azure, the Sync Framework to perform the actual synchronization and the Access Control Service to handle authentication.
I have not used any of this technologies before so any advice would be great but I'm searching foremost for errors or shortcomings in this strategy I don't see yet. Is this approach viable at all?
Windows Azure is basically a virtualized datacentre. It is elaborate and complicated and is pitched at corporations who don't want to own their server infrastructure or hardware.
If I understand correctly, what you want is a cloud fileserver, not a whole LAN. Windows SkyDrive fulfils this requirement nicely and offers 25GB of storage per member with no charge for membership.
About Hotmail and Windows Live People often confuse Hotmail and
Windows Live, because when you set up a Hotmail account it uses
Windows Live for authentication and therefore you end up with a
Windows Live account and all the associated facilities, including
SkyDrive. However, it is entirely possible to set up a Windows Live
account using any email address as the username.
If you do this, it is important to be aware that the Windows Live
password associated with a given email address is completely
independent of the password required by the mail server that hosts
mail for the account. This can cause a great deal of user confusion.
For Hotmail (or any other mail server that uses Windows Live for
authentication) they are guaranteed to be the same password.
There is no official Microsoft framework support for SkyDrive. There is an open source project called SkyDriveApiClient, but it only works with the full .NET framework. I tried porting it but the author was a bit of an architecture astronaut, and it is absolutely riddled with [Serializable] which is not available on WP7x.
The WP7 guys have said that the WP7 framework will probably include support for SkyDrive but not in Mango (WP7.1) and given that Microsoft's typical release cycle is 18 months and Mango has yet to hit the streets, I'd say it will be two years before you can count on intrinsic cloud file services for WP7.
Roll-your-own wouldn't be hard, WCF services are dead easy to use from WP7. But that's not really cloud since you have to provide and maintain the server infrastructure yourself. For this reason and given the MS timetable, I have put a great deal of effort into producing my own SkyDrive client for WP7. Core functionality is complete and I am now refactoring, improving robustness and adding performance enhancements like local cacheing of tokens (cookies, essentially). I don't intend to release it; I have a number of apps planned that depend on this functionality and it suits me fine that there is a substantial barrier to competition.
I didn't tell you that to tease you. My point is that I'm so sure SkyDrive is the right answer that I put a lot of work into making it happen.
Cloud file storage is a perfect fit for mobile devices.
Azure is not a good answer for the sort of phone apps individuals want because the data store isn't shared in a way that required indexing or supports high levels of concurrency
I can certainly think of corporate phone apps that would benefit from using SQL Server as storage
Azure can do file services but it represents an ongoing expense. Nobody's going to put up with that when Google and Microsoft both give away web based cloud storage.
I can personally attest that if you're determined, it is possible to use SkyDrive from WP7.
Cloud storage is the only way you're going to get programmatically accessible storage that's shared by your user's mobile device and his computer. One of the things I intend to do that depends on shared storage is write a Silverlight app that lets you prepare map routes with multiple waypoints on a desktop computer and a companion app that uses them on WP7.
The Windows Live team has released what they call support for WP7. They supply a sample project showing you how to instantiate a browser object and load their login pages and manipulate them to log in and use their javascript API to manipulate SkyDrive.
This has one big advantage: browser cookies and cached credentials. The disadvantages are obvious; technical shortcomings notwithstanding the Windows Live team seems to think the only thing people want to do with a phone is tag their photos and fiddle with social media.
I have finished my own libraries. They do not support most of the social media twaddle. I have treated SkyDrive as no more or less than a cloud file system, providing
Authenticate(username, password)
CreateFolder(folderpath[, blocking=false])
Delete(fileOrFolderPath[, blocking=false])
SaveString(filepath, value[, blocking=false])
LoadString(filepath)
I could handle binaries but Convert.ToBase64 makes this unnecessary and strings are convenient for XML. CreateFolder, Delete and SaveString are optionally blocking. LoadString is always blocking because it's a function that returns the loaded string. CreateFolder is recursive so you can create an entire path in one call (eg /folder1/folder2/folder3). Calling CreateFolder on a pre-existing path has no effect, and SaveString uses CreateFolder to ensure the path is valid, making it unnecessary to create a filepath in advance. Authenticate loads the file system (except file content) into memory eliminating server chatter. This is asynchronous and a FileSystemReady event announces when the file system is completely loaded. The model is maintained as you add and remove files and folders.
This was a lot of work and no one reponded to my attempt to make it an open source project so I'm not inclined to give the fruits of my labour away, but provided your plans don't compete with mine I could be persuaded to come to an arrangement.