Is it possible that a website uses the models of another lavarel website to access the database, without the first website having the sql credentials hardcoded. But with the credentials to log into the second lavarel website hardcoded.
This way the first website doesn't have to have the sql credentials on it's ftp server, but can still access the databases through the other website (with their personal login of that website).
If that is impossible, I am wondering, is there a way to access a databases without having to hardcode the credentials anywhere.
UPDATE (the actual problem)
Only a part of the database should be visible to a particular user, so i can provide different users with different credentials and they all see something different in the database
What you are talking about is an API. So you'd build out the entire infrastructure on the first website, then on the second website, it would make some kind of calls to the first website to get back the information it needs, usually using some kind of credentials or access token.
This way, you can allow anyone in the world to communicate with your website, kind of like how Facebook, or Twitter does.
As far as accessing your database, you would need to tell your app somewhere the credentials to use, so technically, you do need to hardcode them somewhere as they can't just magically make up some credentials somehow to access a database.
if your different users are defined:
use laravel model/db event to replicate the data to a database by
user.
Or sync each database with a cron job..
These have benefits to avoid security transport problems.
Related
Sorry for may be simple question. I not experienced with server-based apps developing.
I study Azure recently and create simple mobile application that connect to azure database. Its make some trivial operations on tables like add items and make SQL select queries. Now I want add authorisation to app and restrict some operations with tables in db based on it. What is best way to do it? I think it's a good idea to write backend on azure server with authorisation-based rules but I don't find out about it from Azure documentation. For example what I want to achieve:
Not authorisation mobile app user restricted to make any modifying operations and can select only predefined columns.
Authorisation user can make add/update operations on some tables based on user info(uid/login etc...).
If I create database rules on frontend(mobile app) side its not difficult to write another app that have possibility to make anything with database in bypass of my app. Isn't it?
If I create database rules on frontend(mobile app) side its not difficult to write another app that have possibility to make anything with database in bypass of my app. Isn't it?
This is very true; security shouldn't be (just) in the frontend. Make sure your backend is set up in such a way it checks the access rules each time someone tries to do something in the backend.
Now, as far as your question goes: please implement an API that connects to your database. With each and every client directly connecting to your database, you will lose all control. If you implement an API in front, you can do stuff like caching and asynchronous processing if you need to.
When implementing the API, you can have the GET methods be unsecured, while POST, PUT and DELETE use a (for instance) JWT token retrieved from Azure Active Directory. This repo and the presentation it links to might give you some reference.
I don't want to store passwords on my server and I don't want to force my end users to create yet another account, that's why I'd like to use single sign-on. I'm looking for a widely accepted solution for the authentication, I think about OpenID and OpenID Connect, the former seems to be more widespread but obsoleted and no longer used by Google, the latter seems to be faster (thanks to JSON?), safer but less widely adopted.
I'd like to share some documents on Internet. I want to control who can view them. I have looked at OwnCloud but it seems to be too much for my needs.
My website contains some photos and some articles, I want to show some of them to everybody, I want to show some of them only to my family and my best friends but not my colleagues, I want to show some of them to all logged users but not everybody and finally, I want to show some of them to … nobody.
I use Apache HTTP Server, I want to be able to manage file access rights for my end users with their own means of authentication. I have looked at mod_auth_oid and mod_auth_oid_file, it handles the authentication with OpenID 2.0, it allows to define a mapping between OpenID and local user ids. Does it mean that I still have to store a password for each local user anywhere on my server?
A graceful server restart is required in order to load new mapping definitions
It's a bit annoying as I don't want to restart the server each time I edit the mapping. It's unclear to me whether it is still true when using mod_auth_oid_ldap. I really need an open source software that I can install on my server and adapt to my needs. I plan to use openid-selector with the Apache modules I mentioned earlier and some JavaScript code to handle gracefully the display of the forbidden content. Am I missing a more obvious solution? I'm not a big fan of Facebook but is this bridge working?
I need that in a Intranet application that is made with Play Framework 2, the credentials that the users have for authentication can also be used to authenticate to the database and that every statement sent to it also uses this credentials.
In other words, to each user of the application corresponds a database user and password.
Thanks in advance.
This means you won't be able to use the connection pool, and instead you will create a connection-per-request sort of, right? No built in support in play for this, but probably not very hard to do yourself.
The exact solution depends on how you will access your database (Slick, ANORM, something else?) but basically you will have to create some abstraction that takes auth and creates a database session that your database interacting code will use.
I wish to create a functionality that is very similar to facebook or pokerstars if you have used them before. Basically the apps require the user to login and their information can be accessed from both browsers and native and web apps.
How can I go about achieving this? Please advice on what services to research on to accomplish this. To my current understanding. I would be creating the website in html and php and creating a webservice using RESTful protocols and hosting them on amazon aws servers. I can then connect to these servers in the native apps? I am not very clear on how the native apps will interact with the servers
If you know of any particular protocol or a better server hosting service please let me know.
If I'm interpreting your question correctly, you are looking for something like this:
The user starts either your browser app or your native app (perhaps a mobile app)
Since the user does not have an account yet, you present them with the appropriate dialog to create said account.
You then ask the "Identity Service" to create a profile for that user
The identity service returns a token for access
This is something we do in the mobile network industry all the time. Technically, we have TAC/ACS or HSS profile services, but in either case, it's the same thing -- a dedicated service and network process that:
Accepts connections from various clients (web, mobile, desktop...)
Has various primitives along the database CRUD (Create, Read, Update, Delete) model
Answers requests the database
If you want a pre-configured solution, you could just use any networked database with a RESTstyle connector for example (MongoDB maybe?) But you could also just through this in a process that talks to a NoSQL or SQLLite database. The end result is the same.
For commercial solutions, I might like at OpenStack as you can run your code on it and they have identity brokers you might be able to CoOpt.
Personally, I'd just have a datastore running on a cloud somewhere like Amazon's EC2 which answers RESTful requests such as:
Create a user with a given profile set, return a unique token
Delete a user given a token
Update elements of the profile for a given token
I'm leaving out the necessary things like security here, but you get the idea.
This also has the advantage that you can have a single identity service for all of your applications/application services. The specifics for a given application element are just sub-fields in the profile. This gives you, not only a common identity broker for web, desktop and mobile, but a single-sign-on for all your applications. The user signs in once and is authenticated for everything you have. Moving from site to site, now just became seamless.
Lastly, you place your identity management, backup, security token management, etc OUTSIDE of your application. If you later want to add Google Authenticator for second-factor authentication, you don't have to add it to every application you have.
I should also add that you don't want to keep the identity database on the direct internet connection point. Someone could make your life difficult and get ahold it later on. Rather, you want your identity server to have a private link to it. Then do something like this:
When the account is created, don't store passwords, store hashes -- much safer
Have your application (web or otherwise) compute a key as the login
In this case, the user might enter a username and password, but the application or website would convert it into a token. THAT is what you send across.
Next, using that token (and suitable security magic), use THAT as the owner key
Send that key to the datastore and retrieve any needed values
Encrypt them back into a blob with the token
Send the block
THe application decrypts the blob to get at values
Why do we do this?
First, if someone were to try to get at your identity database, there's nothing useful. It contains only opaque tokens for logins, and blobs of encrypted data. Go ahead -- take the database. We don't care.
Second, sniffing the transport gets an attacker nothing -- again, it's all encrypted blobs.
This means later on, when you have five applications using the broker, and someone hacks the network and steals the database, you don't care, because your users never gave out logins and passwords in the first place, and even if they did, the data itself is garbage to anyone without the user key.
Does this help?
Should the HTML5 database be used to store any form of private information?
Say we have the following scenario;
You're browsing a web-mail client, that uses the web database to store mail drafts after you've written some information you close the web browser. What's to stop me from getting access to this information?
If the webpage tries to clean out old information when opened a user-script could easily prevent the website from fully loading and then search through the database. Furthermore the names of databases and tables are easily available through the web-mail client's source.
W3C Draft
The only way an external party could access the user's database is via direct access to the user's computer, or if your web app has a security vulnerability (such as XSS - Cross Site Scripting). Otherwise standard browser security dictates that only scripts running in web pages from a certain domain can access databases that were created/stored on that same domain (same origin-policy), same thing that stops you making cross-domain Ajax requests, or reading other website's cookies, all of which can be overcome via an XSS attack.
To me, storing a draft email seems reasonably sensible, whereas things like credit card details, passwords etc. should be stored exclusively server-side. You'll need to make a call as to what should be stored where, based on what you're going to store.
Should the HTML5 database be used to store any kind of private information?
Depends on how sensitive the information is. I wouldn't want to leave credit card details lying around anywhere.
You're browsing a web-mail client, that uses the web database to store mail drafts after you've written some information you close the web browser. What's to stop me to get access to this information?
Assuming you don't have physical access to the computer (in which case the user needs to take relatively extreme security measures) and you don't run the email service (in which case you need to have access to emails) then standard browser security stops you.