I would like to be able to have my login work in development mode (localhost:3000) as well as on the production server, and ideally, on a staging server.
Apparently you can only configure one domain for login, unlike Google apps, which is much smarter.
Maybe I could rig up my hosts file to do something spiffy with a subdomain?
Under Basic Info: App Domains, you can put in your domain. It will handle all subdomains if you just put in the main domain name: '<yourdomain>.com' So it will definitely be able to handle your dev.yourdomain.com, qa.yourdomain.com, staging.yourdomain.com, etc.
As for your local development, that's where it gets tricky. You can't use multiple domains, as you've noted. You can definitely try to follow this answer: https://stackoverflow.com/a/7493806/183880 which involves creating a second Facebook app and configuring the domain to localhost.
I'm not sure if anyone else has solved it yet, but I came across the problem where if you are trying to develop Open Graph actions and objects, it's pretty much difficult if not impossible to develop those locally. This is because the Facebook servers need to be able to access the Open Graph object urls. And in this case since you'll be developing locally, they can't access http://localhost:3000/my-object-url. Somehow you need to be able to expose your local environment to the external world. More trouble than it's worth, in my opinon. My only work around is to just deploy to a development server http://dev.yourdomain.com and test from there.
Related
I couldn't find information on how other people solve this, so maybe you can help me out.
What I have
Multiple Services with REST APIs, that are secured using OpenID Connect. Connections between the Services work fine.
Now I have multiple developers, who sometimes need to write and execute local scripts (Python, R, Bash etc.) for quick analysis and testing.
What I want
I want to enable the developers to use the services as easy as possible, but still respecting security concerns.
What I tried
I defined the script itself as a client. Therefore I created a public client in my OIDC product, which is called somewhat like 'developer-scripts'. Using a library which handles the oauth dance, I can then execute the script connecting as aforesaid client. First time, the browser pops up and requests the user to authenticate and therefore authorize the client to use the REST API on behalf of the user. After that, the tokens are cached and I can easily continue working on that script.
This simplified drawing tries to summarize, what I just described
That works perfectly fine and regarding security I'm glad that credentials are not saved on the local computers as it was before with e.g. Basic Authentication. Furthermore, I'm able to control the access to different services on a user level.
Other ideas, which didn't convince me:
every web service also has an public client which can then be used as a client by the scripts (so the scripts aren't defined as clients anymore)
token generation is done somewhere else and the developer just adds the generated access/refresh token to the script
My problem
What concerns me about my current solution is the definition of that client. In the described case it would be either a generic client used by all developers for all scripts, or a new client for every developer who want's to write a local script. The latter seems to be a lot of overhead, the former may be a security problem?
So finally I'm asking the question: Are there any known best practices for my described use case?
EDIT:
I found a small article by [Martin Fowler](https://martinfowler.com/articles/command-line-google.html), he is basically explaining, how he is receiving a token to use for a local script. But in his case, he's using it for one certain use case, and not as a general public client. So unfortunately it doesn't really contribute to my answer.
I am making a tiny desktop application for my personal use. (Also for a few of my friends.) As part of this application, I am using OAuth 2 to access some of Google's APIs.
I want to eventually upload this to a server where potentially anyone could download it. So I can't just bundle the client_secret with the application.
So, I would like to know, how do open source applications that share there entire source code deal with this?
I could just require users to get their own client_id from google. But that's a bit of a cumbersome process, and I would ultimately end up writing a scraper to do it automatically, defeating the purpose, also it would be very brittle.
Alternatively, there is this question where the answer is to run your own server to act as a middle agent. However, because this is only a small app I'm doing for me and a few friends, I don't really want to manage a server just for this, and even if I did, it certainly would be fairly unstable.
In short, are there any solutions here that
allow me to put my source code on the internet,
don't require me to run my own server, and
don't require my users to go get there own 'client_id' after they've already downloaded my desktop application, or require me to make a web scraper that does it for them?
I want to set up an intranet that can be accessed in more than one location.
I want the server to be located in one location and be accessed in another. For example it would be at the users home, or in one of our many offices. At the moment I can't see more than 7 people using it, so we won't need anything large to start off with.
I use Wampserver for building our webpages, but I don't think Wampserver will be enough to do what we need. As if I set up Wampserver it is only accessible from the building we are in. I do not want to open the firewall to put it online as the pages that we will be serving will not be for the public.
The typical way of doing this is to set up and configure a VPN solution for your home users. You could do this yourself or use a third party solution. Normally, you would allow VPN users access to specific resources, such as your intranet server.
The other alternative is to allow public access to the intranet server, but implement authentication on the intranet server so only your users can access the content.
I would normally go for the former as a more secure solution, but it depends on your environment and requirements.
I'm looking at some (PHP) Frameworks, and I just noticed this in the Laravel documentation:
Like most web-development frameworks, Laravel is designed to protect your application code, bundles, and local storage by placing only files that are necessarily public in the web server's DocumentRoot. This prevents some types of server misconfiguration from making your code (including database passwords and other configuration data) accessible through the web server. It's best to be safe.
I'm familiar with CodeIgniter and CakePHP, as far as I know, these two frameworks don't do this. Should you really split it up and place your core logic outside of the webroot? In my experience, most clients use shared hosting and are not able to change their VirtualHost settings.
What kind of misconfiguration could you possibly do that would output your passwords? When developing, should you really do this?
Yes, keeping only those files which should be publicly accessible in DocumentRoot is a best practice for web application security. Consider:
Every file which is private would need a rule configured with the web server to explicitly block it.
Anyone adding files to the project needs to consider web server security settings. Simply keeping the files in separate directories makes it obvious what's public. And developers don't need to change security configurations.
Separating executable code and static files is a good practice anyway.
Not blocking access to PHP scripts can cause unintended consequences. For example, you may have a script to update some DB records when run manually at the command line, so someone simply guessing a script name can run it over the internet.
Monitoring for and cleaning malicious code written to the public directory is much easier if the real application logic is elsewhere. See Wordpress breakins for an example.
CakePHP supports this - see deployment:
CakePHP applications should have the document root set to the
application’s app/webroot. This makes the application and
configuration files inaccessible through a URL.
Im new to website development and design so apologize in advance if the question is redundant.
I have a program where a client, using a URL string fetches a XML file from a webserver. This would be no problem right if it were a simple URL with no security or no CMS (like Joomla) involved: Just put the exact URL string and the client gets the file from the web server, done.
But, how would the process work if the URL is on my site hosted on GoDaddy and using a Joomla CMS?
Im trying to understand how the same process of fetching a file works on a hosted server using a CMS. Since I just made the transition from my site being on my school's servers to having a Joomla website Im hosting on goDaddy.
I mean where would I put the file if I also want the file to be accessible only if the client authenticates itself first. Just to be on the safe side. I mean is this how normally things work in mobile apps? I have a client program thats a iPhone app and within the app I have a XML file which is used as a data source for my UITavleView, but I want to check some URL to see if an updated version of the XML file exists. My app side programming is mostly done, now Im trying to learn the server side things I need to do to make this process happen with Joomla and my own hosted site
I donot understand how would the process work in that case. I mean, what are the things I would need to do on the server side to and the client side to make this possible?
Please help me understand or if you could point me to some links where these steps are illustrated...or if you could give me some Google key words I can search for to learn about this process.
thanks a lot
The fact that you have a CMS does not generally change how you access a file within the file structure of your domain unless the CMS protects certain directories. In this case, Joomla does not so you can directly access any file you wish. Depending on the sensitivity of the information you are trying to retrieve, you can protect the directory through your domain management panel. If it's not particularly sensitive, the authentication can be done by the app since the URL you are accessing can be easily hidden from the user.
It seems like that would be the simplest solution since the app will have access to user information by nature of where it resides.