I can't seem to find anything official about this: Does Parse.Config work on Parse Server? It used to work on Parse.com but when I try to migrate to Parse.Server, when trying the REST API it seem to fail:
GET http://localhost:1337/parse/config
Passing in my app ID. I read somewhere Config does not work on Parse Server, but wanted to confirm
Although is not officially supported as mentioned on the docs,there is a way to make it work. It is still an experimental implementation though.
As mentioned here & here, you should set the environment variable:
PARSE_EXPERIMENTAL_CONFIG_ENABLED=1
Then restart your node server. In case you deployed it on heroku for example you should on cli heroku restart -a <APP_NAME>
If that doesn't work I would suggest to simply add your route with your configuration options on your project's index.js file where express is initialized like so.
var parseConfig = {
"params": { /*...put your options here*/ }
};
// :one? is for old SDK compatibility while is optional parameter.
app.all('/parse/:one?/config', function (req, res) {
res.json(parseConfig);
});
Related
I am using curl to publish to maven:
const curlOptions = [
'--silent',
'--output', '/dev/stderr',
'--write-out', '"%{http_code}"',
'--upload-file', fileLocation,
'--noproxy', options.noproxy ? options.noproxy : '127.0.0.1',
'--fail'
];
const curlCmd = ['curl', curlOptions.join(' '), targetUri].join(' ');
const childProcess = exec(curlCmd, execOptions, function (error) {
if (error) {
console.log(chalk.red(error));
}
});
This works for the upload but the artefact gets cached and I cannot get the artefact from curl without going to nexus and running rebuild metadata on the affected artifact.
Can i programmatically invalidate the cache?
To answer your question directly, it should be possible to invalidate cache in later versions of NXRM3 using the REST API and the "/beta/repositories/{repositoryName}/invalidate-cache" endpoint.
It should also be possible to do the same and run the scheduled task (rebuild metadata; /v1/tasks/{id}/run endpoint) though that seems a less desirable route as that is generally used for repair.
You can see more on the REST API in the NXRM3 documentation though the intent of some is that it's self documenting by using the Swagger UI in the application. Note at time of this answer, only those with the nx-admin privilege can access the Swagger UI (though people with proper permission can use the endpoints). You can find the Swagger UI in the Admin section under System -> API.
That being said, I think there's likely something else going on. I don't think it should be necessary to invalidate your cache like that each time. I didn't want to go too far from the question however. I encourage you to look at community.sonatype.com for answers to what else might be going on and ask there if you don't see one.
I'm testing out deploying my own parse server following the steps in the Parse Server Guide. I've got the server up and running and have been able to create and fetch objects via curl. I built a simple iOS app using the Parse SDK (1.14.2). I've initialized the SDK with the app id and server url as described in the Parse Server Guide. When I try to make requests, I get back unauthorized from the server. Digging further, I noticed that the SDK is not sending the application id header to the server. I modified the SDK to send the application id header and everything works. Am I missing a configuration step somewhere?
This is because you are not passing the ClientKey. In swift 3 you would pass it like this in the didFinishLaunchingWithOptions.
// Init Parse
let configuration = ParseClientConfiguration {
$0.applicationId = PARSE_APP_KEY
$0.clientKey = PARSE_CLIENT_KEY
$0.server = PARSE_SERVER_URL
$0.isLocalDatastoreEnabled = true
}
Parse.initialize(with: configuration)
If you are falling when trying to test CloudCode, then its because your parse-server is not passing the Javascript key. So just make sure you initialize the server to do so if this issue is related to Parse.Cloud function.
I'm trying to use express-stormpath on my Heroku app. I'm following the docs here, and my code is super simple:
var express = require('express');
var app = express();
var stormpath = require('express-stormpath');
app.use(stormpath.init(app, {
website: true
}));
app.on('stormpath.ready', function() {
app.listen(3000);
});
I've already looked at this question and followed the Heroku devcenter docs. The docs say that for an Heroku app, it's not necessary to pass in options, but I've still tried passing in options and nothing works. For example, I've tried this:
app.use(stormpath.init(app, {
// client: {
// file: './xxx.properties'
// },
client: {
apiKey: {
file: './xxx.properties',
id: process.env.STORMPATH_API_KEY_ID || 'xxx',
secret: process.env.STORMPATH_API_KEY_SECRET || 'xxx'
}
},
application: {
href: 'https://api.stormpath.com/v1/applications/blah'
},
}));
To try and see what's going on, I added a console.log line to the stormpath-config strategy valdiator to print the client object, and it gives me this:
{ file: './apiKey-xxx.properties',
id: 'xxx',
secret: 'xxx' }
{ file: null, id: null, secret: null }
Error: API key ID and secret is required.
Why is it getting called twice, and the second time around, why does the client object have null values for the file, id and secret?
When I run heroku config | grep STORMPATH, I get
STORMPATH_API_KEY_ID: xxxx
STORMPATH_API_KEY_SECRET: xxxx
STORMPATH_URL: https://api.stormpath.com/v1/applications/[myappurl]
I'm the original author of the express-stormpath library, and also wrote the Heroku documentation for Stormpath.
This is 100% my fault, and is a documentation / configuration bug on Stormpath's side of things.
Back in the day, all of our libraries looked for several environment variables by default:
STORMPATH_URL (your Application URL)
STORMPATH_API_KEY_ID
STORMPATH_API_KEY_SECRET
However, a while ago, we started upgrading our libraries, and realized that we wanted to go with a more standard approach across all of our supported languages / frameworks / etc. In order to make things more explicit, we essentially renamed the variables we look for by default, to:
STORMPATH_APPLICATION_HREF
STORMPATH_CLIENT_APIKEY_ID
STORMPATH_CLIENT_APIKEY_SECRET
Unfortunately, we did not yet update our Heroku integration or documentation to reflect these changes, which is why you just ran into this nasty issue.
I just submitted a ticket to our Engineering team to fix the names of the variables that our Heroku addon provisions by default to include our new ones, and I'm going to be updating our Heroku documentation later this afternoon to fix this for anyone else in the future.
I'm sincerely sorry about all the confusion / frustration. Sometimes these things slip through the cracks, and experiences like this make me realize we need better testing in place to catch this stuff earlier.
I'll be working on some changes internally to make sure we have a better process around rolling out updates like this one.
If you want a free Stormpath t-shirt, hit me up and I'll get one shipped out to you as a small way to say 'thanks' for putting up with the annoyance: randall#stormpath.com
After endless hours, I managed to finally get it working by removing the add-on entirely and re-installing it via the Heroku CLI and then exporting variables STORMPATH_CLIENT_APIKEY_ID and STORMPATH_CLIENT_APIKEY_SECRET. For some reason, installing it via the Heroku Dashboard causes express-stormpath to not find the apiKey and secret fields (even if you export variables).
In parse.com, when I want to create new app, I use:
curl -X POST \
-H "X-Parse-Email: <PARSE_ACCOUNT_EMAIL>" \
-H "X-Parse-Password: <PARSE_ACCOUNT_PASSWORD>" \
-H "Content-Type: application/json" \
-d '{"appName":"my new app","clientClassCreationEnabled":false}' \
https://api.parse.com/1/apps
But when I deployed Parse server to Heroku and Digital Ocean, I didn't know to create new app, because my server doesn't have PARSE_ACCOUNT_EMAIL and PARSE_ACCOUNT_PASSWORD. When I deployed parse dashboard, it didn't have "Create a new app" like Parse.com.
How can I create new app with my self-hosted Parse server?
The self hosted parse servers can only handle one app per server, at least for now.
This means that you will have to use several installations of Parse, one app per installation using multiple servers or multiple instances of parse on the same server but configure each server to use different ports.
To answer you question: No you do not need to use parse.com to create new apps.
To create a new app you set the appID and password in the parse config/start file on your digital ocean or other hosted server.
The appID and password can be anything that you make up, it does not need to be from parse.com.
Below is an example of the environment settings in a startup file:
**Example file: ~/parse-server-example/my_app.js**
var express = require('express');
var ParseServer = require('parse-server').ParseServer;
// Configure the Parse API
var api = new ParseServer({
databaseURI: 'mongodb://localhost:27017/dev',
cloud: __dirname + '/cloud/main.js',
appId: 'myOtherAppId',
masterKey: 'myMasterKey'
});
var app = express();
// Serve the Parse API on the /parse URL prefix
app.use('/myparseapp', api);
// Listen for connections on port 1337
var port = 9999;
app.listen(port, function() {
console.log('parse-server-example running on port ' + port + '.');
});
Then run the file with:
node my_app.js
You can read more here: Parse Server at Digital Ocean
There is an open issue for that: https://github.com/ParsePlatform/parse-dashboard/issues/188
For the moment, I just use parse's hosted dashboard to create new apps. They say on January 28th, calls to their API will cease to function. They don't say that the hosted dashboard will be going away. I imagine that, if they don't get it into the self-hosted version, you'll still be able to create new apps within the hosted dashboard.
In any case, for now what I am doing is creating the app as I normally would in the hosted dashboard. I then run the migration tool at app > app settings > general > Migrate to external database option. You have to add at least one class to the database in order for the migration tool to work. Basically, the migration tool will fail with some ambiguous error message if it's a completely fresh app with a clean database.
Once the migration is done and read/writes are hooked up to my self-hosted Parse Server, I then providing the app's keys, etc in the parse-dashboard-config.json file of my self-hosted Parse Dashboard. You can add multiple apps to this config file, thus manage all of your apps from a single self-hosted Parse Dashboard.
Here's an example of that config file with two apps:
{
"apps": [
{
"serverURL": "https://my-parse-server-1.herokuapp.com/parse",
"appId": "b44gL7uAB1z...lwUJneaoKdX9",
"masterKey": "HrSqFbH...hfiwuCCOLDvHF",
"appName": "parse-server-1"
},
{
"serverURL": "https://my-parse-server-2.herokuapp.com/parse",
"appId": "b44gL7uAB1z...lwUJneaoKdX9",
"masterKey": "HrSqFbH...hfiwuCCOLDvHF",
"appName": "parse-server-2"
}
],
"users": [
{
"user":"admin",
"pass":"somePasswordHere"
}
]
}
This seems to be the only way currently to create apps that you can connect to your self-hosted Parse Dashboard.
It's also important to note that, at the moment, it appears as though the self-hosted Parse Server package only supports a single app. I have no idea if there are any plans to support multiple apps as they have done with Parse Dashboard.
And finally, you can use the Parse Command Line tool to create new apps as well: https://parse.com/docs/cloudcode/guide#command-line-creating-a-parse-app
They also have some interesting integrations with Heroku which facilitate the entire process. That might be worth looking into. You could create a simple Node app yourself with a GUI for creating new Parse apps. In this case, you would create a simple form, that when submitted is validated and then executes the command line methods to create a new app with the ShellJS node package. You could even modify the Parse Dashboard package to include this feature yourself within the self-hosted Dashboard.
I recently implemented the security of my Parse app thinking that I could use the master key on my server (express not cloud code) to securely bypass my security implementations for admin/server level functions.
I'm using "parse": "^1.5.0",
in my package.json.
Right now in each of my express modules I have:
var Parse = require('parse').Parse;
Parse.initialize("Application ID", "Javascript Key", "Master Key");
Everything works fine without CLPs activated but with CLPs I can't do any read/write of the data with the server. I understand that I can move this to Cloud code and get it to work however I need to use a number of libraries in my code that Parse does not support and transporting all of the code to cloud code would be very tough.
What am I doing wrong?
Here's what worked for me.
/////////////////////////////////this is the top of the JS page/module/////
'use strict';
var Parse = require('parse/node');
Parse.initialize('app-id','js-key','master-key');
exports.create = function(req, res) {
Parse.Cloud.useMasterKey();
//now when you do a parse query or action you can bypass your security settings.
};