I am trying to build a website with the Play framework that will need to request some directions from the google maps api.
For those requests, I need to use my google api key. Obviously, I don't want to hardcode this value for multiple reasons. Is there a specific file configuration file that is suited for this usage in the Play framework?
It sounds like you don't want to hardcode your key for security reasons - ie. you are checking into a public Github repository, in which case you have a couple of options:
I usually use an environment variable for local development:
maps.api.key=${?MAPS_API_KEY}
ie. where MAPS_API_KEY is an environment variable configured on your machine.
For production deployment I either:-
1.) Set the value dynamically at build time from a private property file. Usually my approach if using a CI tool for the build.
2.) You could also pass it in as a system variable at startup:
/path/to/yourapp/bin/yourapp -Dmaps.api.key="YOURKEY"
You will need to modify your startup script if using activator dist to create your distribution.
Related
It is well known that nextjs API routes provide a straightforward solution to build your API with Next.js. and that any file inside the folder pages/api is mapped to /api/* and will be treated as an API endpoint instead of a page.
I have just one doubt: is the code within the pages/api exposed to the world? I mean, can I build some logic there that has some key that must be hidden or maybe some MySQL connection?
Whether or not /api is in any way exposed to the world I do not know for sure, but according to Next documentation, "they are server-side only bundles."
In general though, for any key/sql connection that you want to run, I would put that into an .env.local file on your machine, a file that gets git ignored and never uploaded, and if you are hosting on Vercel, then use their environmental variables to store sensitive information.
You'd find environmental variables under:
{Your Account}/{Project}/Settings/Environmental Variables
p.s. Also from Next.js docs, I think you'd find this bit on getStaticProps useful.
I define a route for my cloudfoundry app in its manifest file:
---
...
routes:
- route: example.com
My route gets successfully created during 'cf push' but unfortunately the default route gets created as well, i.e. I have two routes and I want only the one I defined in my manifest.
Any ideas how to get rid of the default route?
I know it is possible to remove routes, but as 'cf push' is triggered via a jenkins pipeline in my case I'd like to define everything in advance in the configuration. I assume that the manifest file is the best place to do so.
Even better would be if I can move the definition of the route into a manifest-variables file, but I'm trying it in the manifest file directly at the moment to be sure that this is not the source of my issue as I don't have much experience with it yet.
Thanks and beste regards,
Yvonne
This should work, I just tried this against Pivotal Web Services, for which CAPI is always kept pretty up to date (currently API version 2.142.0) and it worked just fine, only creating the route I specified. Which version of Cloud Foundry are you using? Also, I haven't checked if there is such a configuration but maybe your Cloud Foundry instance is configured to always create a route on the default shared domain.
One of the other possibilities is to use the commands unmap-route and map-route to map and unmap the routes of a specific application.
I wanted my Grails 3.1.5 app to serve both JSON data using the *.gson format AND, for some pages/URLs I wanted to continue to use GSPs.
I built an app using the rest-api profile.
Then I copied over controllers and views from an other app that I'd built using the web-api.
In doing so, and to be consistent, I also moved index.gson to a different location.
Now I get a:
Could not resolve view with name 'index' in servlet with name 'grailsDispatcherServlet'
Started digging into the viewResolvers that are available in the 3.1.5 code base. It is possible that the rest-api profile configures a viewResolver to look for *.gson files in a certain location.
Is there anyway to configure maybe a CompositeViewResolver that looks for both the views, *.gson and *.gsps?
If so, how can I do this?
Thanks!
I've managed to resolve this issue by adding this plugin to build.gradle:
compile 'org.grails:grails-plugin-gsp'
and with both
profile 'org.grails.profiles:web'
profile 'org.grails.profiles:rest-api'
and apply plugins
apply plugin: 'org.grails.grails-web'
apply plugin: 'org.grails.grails-gsp'
apply plugin: 'org.grails.plugins.views-json'
Apparently, they remove it when you're using REST profile, to reduce overhead, as you rarely render HTML on REST service side.
My (java) application (in openshift environment) generates/updates a few html files for each user (based on changes of user data) on daily basis. Since these are application-generated files, they are stored in a directory under ~/jbosseap/ (e.g. ~/jbosseap/htmls/xxxxxx.html). what should be the urls to these html files, by which they can be accessed on internet?
Just an update on how have I solved the problem I presented above. First of all, it is good to rephrase the issue for clarity:
My objective: I have an application which creates/updates a set of html pages regularly. These pages are stored (by the application) in a directory on the file system. For the purpose of this writing, let's say the fullpath to the directory is "/opt/mydata/*".
Users of the app need to access these html pages from internet. Therefore, urls to these pages need to be provided: e.g., http://mycompany.com/static/sample.html for /opt/mydata/sample.html.
My environment: my app is a J2EE application, developed with Springframework 3.1, running in Openshift's jbosseap environment
My solution: add the following line to the (servlet's) context configuration:
<mvc:resources mapping="/static/**" location="file:/opt/mydata/"/>
The trick, I think, is "file:" in the clause to allow inclusion of resources
on a file system external to the application.
It has worked for me. Hope it helps anyone who have wondered too.
Credit Thanks to Eugen Paraschiv, whose post led me to the answer.
We have a SPA web application that we're trying to convert into a WinJS project as a native Windows Store app. For most part, the Javascript is working except for DOM manipulations deemed unsafe.
One thing that does not appear apparent is, how can the start page of the app (e.g. index.html) be supplied with query string and hash parameters? Our site main page is designed to behave differently based on parameters.
e.g. index.html?contextId=xxxxx#enviroment=xxxxx
I tried adjusting the value in package.appxmanifest to no avail. It will throw errors on query strings, and hash parameters will silently not persist.
UPDATE: Project background
A brief about what our app does, and then why the above naive desire won't work and the answer below how we went about this issue.
Our web app is a highly-dynamic data-driven application that completely relies on data to figure out what to render. Therefore the ?contextId=xxxxx parameter is so crucial as it tells our system to load the data which further informs what kinds of visual components to load and it goes on recursively to form wildly different UIs.
We were looking to therefore find some means to supply these parameters like traditional command-line parameters to the same executable to produce different UIs. And thus different "apps" by mere changes in those parameters. Like a "config transform" mechanism for web.config in ASP.NET web projects, that would be most welcome.
However further testing showed it is not possible; a single Windows store app project has a GUID that is supplied into the packaged app bundle. Building the same project multiple times with different "build config" would just mean overwriting a previous installation since they are the same app with increasing version numbers. The answer details how we went about this.
Windows Store apps don't work with URI parameters when launched from their primary tile. In that case, you should make sure that the app defaults to suitable values, e.g., if you were thinking to supply defaults in the manifest, then default to those in the app's activation handler for the ActivationKind.launch case when eventObject.detail.arguments is empty.
There are two other ways to launch an app that can supply other arguments.
First is to launch via a secondary tile. When you create the tile from the app (which is subject to user consent), you supply the launch arguments. In your activation handler, for ActivationKind.launch, those args will be in the eventObject.detail.arguments property.
Second is to launch the app through a URI association. You use a custom schema for this, which is declared in the manifest. The app will then see ActivationKind.protocol and eventObject.detail.uri will contain the full URI including any parameters. A URI launch can be done from another app, by entering the URI into a browser address bar, or through a shortcut that a user could configure on the Start screen.
The first step is to convert our Windows (8.1) Store project into a Universal app structure, which would then spin off a separate Windows Phone WinJS project (this is nice when we wish to target Windows Phone later) and a shared project.
Practically everything from the Windows Store project is moved to the shared project (including default.html or index.html). What remains in the Windows Store project is a customised config.js carrying the parameters
window.customWin8 = {
contextId: xxxxxxxxxx,
customParam: 'xxxxxxxxxx'
};
The downstream modules that sense for query string/hash parameters would then fall back to this alternative object if it exists to pick up the data it needs.
Now, for every differing app we wish to deploy, that would for now seem to require a separate Windows Store project so it gets its own GUID and won't conflict with other apps. All these projects would reference the very same shared project thanks to the Universal structure Visual Studio affords. The only down side is it seems Visual Studio 2013 does not have a direct UI method to make this referencing to the share project and has to be hand code into the jsproj file.
<Import Project="..\Common.Shared\Common.Shared.projitems" Label="Shared" />
With this adjustment they can all build and package with their isolated "build config".