I'd like to start a website that provides users with photos editing/storing experience. The initial idea is that the user has his own account where we store the edited photos and some settings. I'm am a WordPress web developer and when I try to consider how to build such a website in WordPress I don't really understand how to provide such a services without having access to user photos. My idea was to create a custom post type and save it with the user as an author. But as an admin of the website, I will have access to all the created/saved photos and I would like to build it in a way that I don't have it. Is it possible?
I've used previously the app to write a diary that saved the data to my Google Drive and if I understand correctly, it never had access to my files.
So my question is: what are the best practices to build such a resource? Is it normal to have access to all of your user photos if you provide such a platform?
In your case, as you will use WordPress and you are the developer you will always have access to the data of everything.
You will always have a way of knowing which data is from user or which data belongs to another user.
You have two options to do this, but this will take some development work:
1 - You must recreate the way WordPress works where the user is not related to an email and not private data that can relate to the user.
Example: You ask the user to register only that only asks for a hash that can be any word, number, or any other information and a second field would be the password.
With this in the backend you get this two information and do some kind of hash I'll give the example using md5 but do not use it.
After that join these two data and this will be the user.
and to login the user needs to repeat this information and will be within the platform. With this you will be able to maintain the anonymity of the user and will not know who the user is.
In this option you will have for each hash and password a different user :)
But I recommend not using wordpress if you choose this option. You can use a framework like CodeIgniter for example which is super simple.
2 - The second way would be to use the normal wp User, not worrying about who the user is and their information. But one way to keep photo information "anonymous" is to generate a unique hash with each user and have some way of relating the user to it.
Example: When uploading a file to edit it will generate a passkey, you must warn the user that when they want to edit this photo or view they will need to type it into an input. With this you will not know which information is from which user. but it requires extra work for the user
This way you will always have anonymity of user information. I hope I helped you somehow.
Related
I have a Flutter app where most of the users should never log in. I also use this same app for a small selection of users that I personally manage and would like to allow them to create a Firebase account, preferably just with by giving them a password to access the account creation page. Ideally I don't want just anyone to be able to create an account, only those who I have personally given access to. Is there a way I could password protect the account creation page so that only those with access to the password could create an account? Perhaps there is another way to do this? Ideally, I'm not looking to get into a situation where anyone can create an account and then downstream I have to authorize that account so that it has the correct access. I really just want only those with the access upstream to be able to create the account. Perhaps this is not logical but this seems to make more sense than letting accounts be created by anyone and then approved by me after the fact. So my question really is, how do I password protect a page in flutter? Or is this just a bad idea and should I work to manage things downstream? Or is there another solution I have yet to consider?
Have you considered using something like a dynamic link that navigates to the specified page in the app when clicked. firebase_dynamic_links might be of help. Only those who have the link will be able to access it and I presume that you could manage the link actions from the Firebase console.
You could also opt for simplicity and create a password field that pops up before your account creation page
I'm building a Membership site using wordpress and Membership Plugin .
The site is still on my localhost. I did some trial sign ups and it worked perfectly well. But I noticed that, I can use even a fake email address such as xyz#gmail.com or something to sign up and create an account. So that's the problem. I don't know how this will work when I moved the site to my server.
But do you guys think this is a security hole ?
And what can I do for this as a solution ?
Here's what I suggest:
On the registration page, add a field where users need to enter a special code to complete registration and make the code as an image (or at least as something robots cannot process easy). This will prevent robots from constantly signing up to new accounts with bogus information.
Next, perform basic email validation to make sure the format is correct.
Next, strip the email address the user entered and verify the domain part is correct and if it is, have your server automatically send an email to the new account holder asking him/her to return to a special section of the site where he/she enters a special registration code assigned to him/her to complete registration.
Also, to save database space (I'm assuming registration info will be stored in one), ask users to complete registration within a limited time period or they will have to start over. If the time is up then relevant data from the database can be removed. I suggest setting the time period to at least one day.
If you are unable to do this, then you may need to find a better plugin that has the functionality I described.
And whatever you do, play with the website on localhost and make as few modifications on the live server as possible. This means make all changes at once on localhost if you can then upload everything at once to the live server.
I have one requirement like I want to hide the data (lists/libraries/documents) to the users which are forms based authenticated. Windows users can add the data into sharepoint lists. Forms based authenticated users only able to see when ever windows authenticated users give the permission. I thought to create one group for the forms based authentication, but we cannot hide data from them, so this will not work. How to do this ? I am thinking on this, but not able to find the solution.
Any one has any idea?
New Addition:
Actually, there should be two urls (say URL1, URL2) for the same site which we can configure in the alternate access mapping. Only one url (URL2) should be exposed to external users. So, when ever any external user login(Forms user) then we have to show the content which is given access by windows authenticated user. Means when windows users add some content to the URL1 and the give permission for the form authentication users then that content should appear in URL2. By default the content added in the URL1 will be reflected to URL2. But here it should not happen.
Principally, there shouldn't be a problem duplicating your site, and modifying the copy to be more limited than the original.
If both sites are on the same site collection, you can configure them to use the same lists/document libraries.
After you do that, it's simply a matter of configuring AAM to present one site outside, and one inside.
I am working on a specific case where the user authentication is external from the Drupal site. The external site will authenticate the user and return the basic user related data to the Drupal system.
The catch here is that, we are not supposed to have any user data in the Drupal DB. I have checked the user_external_login_register() but it does not work since it saves the user data in the database. So can someone please direct me as to how this can be done.
Thanks so much in advance,
Vinay
user_external_login (http://api.drupal.org/api/function/user_external_login/6) is probably as close as you can get. It ignores the password stored in the drupal users table, so the passwords could be random data if needed.
You could also mash a bunch of data onto global $user to get some semblance of a normal login.
But, you'll only get so far in a drupal environment without storing user info in the database. Many basic operations call the user_load() function, which depends on useful information being available in the database.
For example, most user-based views ("My Groups", "My Recent Posts", etc) call user_load instead of accessing the global $user object.
Encouraged by SO, I'm trying to write an ASP.NET site that uses OpenID for user authentication. It's a regular WinForms site (not MVC.NET), using the DotNetOpenId library for authentication.
Is it safe for me to permit/deny administrative functions on the site by simply comparing the current session's "ClaimedID" (as returned in the OpenIdLogin_LoggedIn event, as member DotNetOpenId.RelyingParty,OpenIdEventArgs.Response.ClaimedIdentifier) to a known administrator's OpenID (i.e. mine)?
If so, is it safe for this ID to be visible (e.g. in open source code), or should it be "hidden" in a configuration file or a database row? (I know it's better design to make it configurable, my question is just about safety.)
My solution is to follow the same idea of the Roles table. After you've authenticated the user, look up that user's roles. If the user has role "Administrator" in the UserRoles table, then they can do whatever the Administrator can do.
I don't broadcast open ID's in my app. They're stored in the table. On every action result, I'm hitting the Users table, since I have also modified mine to store various user state information. With the exception of the home page, there is going to be some user information that I need from that table. I'm using LINQ, so I include the .LoadWith() to load the User with his list of roles when it serializes.
Jarrett makes some good comments about using database tables.
Just to answer another one of your questions, no, it's not a confidentiality thing to put your OpenID in your code generally. If setting up roles seems overkill for your site, a simple equality check against your ClaimedIdentifier is just perfect.