Meteor Npm-module client-side? - client

Is it possible to use Npm-Modules on client-side?
More specifically:
I want to use node.js built-in crypto-module for encrypting a password the user enters and then send the encrypted password with a signature(/hmac) to my server.
I need to do it that way, because I must be able to retrieve the original password server-side, because afterwards I'm going to send it to a ldap-server, because the user should authenticate with the same username/password he is registered with on that server.
This is what I did:
created in packages/crypto/:
-package.js:
Package.on_use(function(api) { api.add_files('crypto.js',['server','client']);});
-crypto.js:
crypto = Npm.require("crypto");
It works fine on the server, but on the client it says "Reference Error: Npm is not defined".
So, is it possible to use the crypto-module on client-side?
Are there any alternatives for achieving this goal?
Thank you!
Edit:
Is there any good alternative for getting the password to the server in a secure way, so that the server can retrieve the original password?
I think doing the ldap()-request on the client-side (like:
if(checkLdap(usrname,password)){<login>} else{fail}) can be easily bypassed?

You can try to add the js-files you need on client-side from .npm folder under crypto's package directory.
So, your package.js file might look like this:
Package.describe({
summary: 'Description of your crypto package'
});
Npm.depends({
'crypto': '1.0.0'
});
Package.on_use(function (api) {
api.add_files('crypto.js', 'server');
api.add_files('.npm/node_modules/crypto/crypto.js', 'client');
});

You can use https://github.com/elidoran/cosmos-browserify now to archive this. I used wrapped packages before and it was real pain to update them and to create new ones. Now with browserify support I can include library with just several lines of code. See their example how to do it. I don't publish it here as it may be subject of change.

Its not possible to use Npm modules on the client side since Npm modules are extensions via node.js which only runs on the server end.
If you want to use a file like crypto you would have to make a client side only version and put it in /client/lib of your Meteor app
While this may be possible officially, Meteor doesn't support this.
You would have to include requirejs manually using this project: https://github.com/apendua/require

You can use browserify to build a .js bundle with all all the Npm modules you want on the client side. See:
2013 Meteor NPM Packages

Related

How to get Rest Api endpoints, name and url's, in the way Azure Functions do?

Sometimes you get over a feature that you just like. When creating a Azure Function project and debugs it, it writes out this nice info in the console.
Now that I am writing the frontend, I have found this information very useful.
Functions:
CoWorkers: [GET,POST] http://localhost:7071/api/CoWorkers
GetManager: [GET,POST] http://localhost:7071/api/GetManager
SetManager: [GET,POST] http://localhost:7071/api/SetManager
UserInfo: [GET,POST] http://localhost:7071/api/UserInfo
...
I would like to have this on every asp.net rest api project that I am coding.
Anyone knows how to get it?
EDIT: OpenApi/Swagger is providing this information as pawelek91 says and I should have mentioned that I want it in the console: "Just because I like that feature".
use HttpOption request or swagger (if you can install it on your backend)
For console access to your web API, try the new HttpRepl tool at:
https://learn.microsoft.com/en-us/aspnet/core/web-api/http-repl/
It's a dotnet CLI tool that is installed separately (install using dotnet tool install -g Microsoft.dotnet-httprepl from the CL). Then you can "browse" your API using this command line tool.
As noted in the docs, it requires .Net Core 2.1+.

Go Get for Google's Cloud Source Repository

Making two different go modules
source.cloud.google.com/me/a
source.cloud.google.com/me/b
With source.cloud.google.com/me/common as a common lib dependency (to share a model)
I'm trying to go get source.cloud.google.com/me/common (even manually wrote it in the go.mod file) but I keep receiving the following error:
package source.cloud.google.com/me/common:
unrecognized import path "source.cloud.google.com/me/common"
(parse https://source.cloud.google.com/me/common?go-get=1: no go-import meta tags ())
I have gcloud set up to be able to use app deploy and create new source repositories. I've tried setting up ssh for google cloud and attempted to use manual credentials. This neither works locally or in the google cloud build service.
I want to do two things:
Be able to go get this dependencsource.cloud.google.com/me/common
Be able to integrate this go get into my App Engine automated build pipeline.
Any help would be appreciated.
Configure repo on https://source.cloud.google.com/
Authorize manual git access https://source.developers.google.com/p/YOUR_PROJECT_ID/r/YOUR_REPO
In this example: https://source.developers.google.com/p/m/r/common
Your common module should go like source.developers.google.com/p/m/r/common.git
Run: go get source.developers.google.com/p/m/r/common.git on the other module
I would try the following steps:
Make sure it has manual git access - You can try a git clone from folder "a" to check if correct git access is in place. Delete it after it gets cloned.
Make sure that you are using HTTPs - looks like you are good in that regards - go1.14 made HTTPs as default for go get's.
Now, coming to the actual problem - looks like your private version control systems isn't sending the required "go-import" meta tag.
For example - refer any github go module, you can see the "go-import" meta tag:
In order to fix it, the VCS server needs to respond with this tag when go get tries to download "common" module
<meta name="go-import" content="source.cloud.google.com/me/common git https:source.cloud.google.com/me/common">
This works:
got get source.developers.google.com/p/YOUR_PROJECT_ID/r/YOUR_REPO.git

How does your workflow looks like with react.js along with backend?

I am developing a simple CRM app using Laravel 5.2 and ReactJS. Previously I was using them independently, but now I want to try to combine them together so Laravel will be my API and front-end will be all in ReactJS.
As far as I know when my app is ready to go live I will serve my master view which includes root div, bundle.js etc.
When it comes to development part I am a little confused. I really love react hot reload, but for now I had to do a little walk around to make this works.
I run two servers side by side. Webpack-dev-server and homestead, so I am able to do calls to my API. But I also have to have additional index.html for webpack-dev-server. When i change something in my index.blade.php view I also need to change this in this index.html and this is a little bit of pain.
Is there any cool trick that I can apply to improve my workflow? If there is any example please provide me a link, because I wasn't able to find one. There are many small todo apps that doesn't really solve my problem.
PS. Currently I am using this approach https://github.com/sexyoung/laravel-react-webpack
#UPDATE
Well I think I have found an acceptable solution. I will stick with webpack server configuration that I have provided in my question (it is really great cause you can use hot reload + you api calls are redirected to backend port, so instead of localhost:8080/api/user... you call /api/user/1), but I have also developed a simple elixir extension that compiles php to simple static HTML page which solves the problem of editing two index files (we all know programmers are lazy).
var php2html = require("gulp-php2html");
var gulp = require("gulp");
var rename = require("gulp-rename");
var Task = elixir.Task;
elixir.extend("php2html", function (message) {
new Task("php2html", function () {
return gulp.src("./resources/views/index.blade.php")
.pipe(php2html())
.pipe(rename('index.html'))
.pipe(gulp.dest("./"));
})
.watch("resources/views/index.blade.php");
});
elixir(function (mix) {
mix.sass('app.scss');
mix.php2html();
});
So at the moment I have two index files:
index.blade.php in resources/views which is resolved by the router on production
index.html in root of my application folder which is used by webpack-dev-server for development
and of course now these files are sync cause of gulp watch :)
If there is any better approach let me know guys.
I have usually solved this problem (duplicated index.html/php file) using this webpack plugin: https://github.com/ampedandwired/html-webpack-plugin
The idea is the opposite of yours I think. Instead of compiling your php files into static html, you can use the HtmlWebpack plugin to output a index.tmpl.php file (or whatever extension you need) using the filename configuration option. Normally I set that path to be the templates folder of my application server.
I believe this approach is generally easier than doing the other way round.
Using this plugin has other benefits, such as automatic bundle script tags injection depending on your Webpack output config, and automatic cache-bursting file hash added to the script tag urls.

What is the correct way to add js libraries to mean.io applications?

I am trying to add underscore to my mean.io application. I'm not sure where to link the js library to the page as it doesn't have a main html page like the Angular generator does.
I manually added it via the config/assets.json file and it works however the dev server keeps crashing saying _ is undefined (even though the web app uses the _ function ok and returns the data just before the dev server stops).
I asume I must be doing this wrong.
What is the correct way to add custom js libraries to a mean.io project?
In your package app.js file add
<your package>.aggregateAsset('js', '../<path_to_js_lib in "public/assets" folder>',{
absolute: false
});

How can I force a meteor app to make all HTTP calls through a proxy?

I'm trying to emulate curl through a proxy server. The meteor docs don't mention any proxy settings for HTTP.* methods.
Is there a meteor-specific solution? Right now I'm using ProxyChains.
Ideally I'd use a SOCKS proxy and only HTTP.* calls would go through it, but I'm open to all calls from the application going through any type of proxy.
Meteor 1.1 update
You can pass options directly to the npm request module via the npmRequestOptions parameter to HTTP.*. The functionality was enabled by this commit made after I filed an issue in 2013 (see below).
You no longer need to use the http-more package.
Old answer, pre-Meteor 1.1
One method would be pass a proxy parameter to HTTP.* calls, which use the request module, which supports proxies as an option.
proxy isn't a recognized option in the HTTP package, and I've filed a request to simply pass through unrecognized options. It was rejected by one of the Meteor core developers.
I'd rather people vote on that issue, asking for unknown options to be passed through instead of being ignored. In the meantime, I've created a package that does pass through options: http-more.
Here's a Meteor proxy package: https://npmjs.org/package/seafish-http-proxy-meteor
It's not available through atmosphere, but it is an npm package designed for meteor, which means it will be very easy to integrate.

Resources