0%

在实际开发中,遇到这样一个问题,公司服务是GitLa,自己的业余项目开发用到了GitHub,两者的账户不同,以我为例,公司邮箱he@company.com,GitHub是个人邮箱he@1991421.cn,我并不想使用同一个Key,希望对于不同的Git服务使用对应的认证信息Key,网上检索后,方法如下。

配置步骤

  • 生成SSH-key
1
2
3
4
5
6
cd ~/.ssh/
# 生成GitHub所需要用的,使用默认名称回车跳过
$ ssh-keygen -t rsa -C "he@1991421.cn"

# 生成GitLab公司所需要用的,进行重命名id_rsa_company
$ ssh-keygen -t rsa -C "he@1991421.cn"

这样两者的密钥就是分开生成了,互不冲突

  • 粘贴公钥到对应的平台
    cat id_rsa.pub
    cat id_rsa_company.pub

  • 配置config
    执行touch config,创建配置文件
    将下面的配置粘贴进去

1
2
3
4
5
6
# company-GitLab
Host compay.com
IdentityFile ~/.ssh/id_rsa_company
# GitHub
Host *
IdentityFile ~/.ssh/id_rsa

​ *即匹配其它所有

  • 检测是否成功
    1
    2
    3
    4
    5
    # GitHub
    ssh -T git@GitHub.com

    # 内网GitLab
    ssh -T git@192.168.1.150
    不报错,说明OK。这样就可以正常的拉取仓库和提交代码了。

用户名/邮箱

令牌区分只是解决了认证权限,但本身提交用户名及邮箱却会是默认全局的配置,如果想个性化,需要在仓库下执行以下命令。

1
2
$ git config [--global] user.name "[name]"
$ git config [--global] user.email "[email address]"

如果想根据不同的类型仓库,比如公司的自动使用一套配置,自己的项目使用另一套呢,这样就不用每次拉取一个仓库都要手动设定一次了。具体如何操作可以戳这里

常见问题

  • ssh登录,提示权限拒绝
    确保密码、配置正确,如果还是提示的话,其实可能性是出在权限上,注意确保.ssh文件夹权限,建议直接777

在实际开发中遇到这样的情况,比如一些外企企业,使用了网络代理,我在后端获取IP,发现存在空的情况。
分析下,原因如下:
当我们应用设定了信任代理的时候,直接使用req.ip获取的会是客户端的真实IP,但是信任代理的话,代理是会修改XXF头部信息的,比如
我遇到的情况就是代理修改请求头,导致我获取的req.ip为空,其实代理改了头,隐藏了真实客户端IP的话,的确我们是不可能得到真实的客户端IP了,但是代理本身的IP还是可以得到的,所以,我就封装了我自己的获取IP方法,

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/**
* 获取客户端IP地址
* req.ips would be ["client", "proxy1", "proxy2"]
* 优先取客户端真实IP或最接近客户端一级的代理IP
*/
util.getClientIP = function (req) {
let ip = req.ip;
if (!ip) {
for (let item in req.ips) {
if (item) {
ip = item;
break;
}
}
logger.info('req.ips');
logger.info(JSON.stringify(req.ips));
}
return ip;
};

这个方案主要是弥补了我单纯使用req.ip获取客户端IP,会存在空的问题。
当然我们也可以设定不信任代理,但是这样子就意味着只获取客户端IP,永远不会知道代理环节的IP,所以代理信任设定,要看实际场景了。

app.enabled(‘trust proxy’)

当设定了信任代理时,express会获得客户端连接请求中的IP地址。

req.ip

使用req.ip获取请求IP地址,当设定了信任代理时,这个值会是X-Forwarded-For header中的最左边值。

1
2
req.ip
// => "127.0.0.1"

req.ips

当设定了信任代理时,这个值会是个IP地址数组,req.ips会是这样 ["client", "proxy1", "proxy2"]

创建平台

1
ionic cordova platform add android 

创建签名文件

1
keytool -genkey -v -keystore he-release.keystore -alias he -keyalg RSA -keysize 2048 -validity 10000

创建签名配置文件

platforms/andoroid下创建release-signing.properties配置文件

1
2
3
4
key.store=<YOUR_KEYSTORE>.keystore
key.store.password=<YOUR_KEYSTORE password>
key.alias=<YOUR_ALIAS>
key.alias.password=<YOUR_ALIAS password>

执行打包命令

ionic cordova build android --prod --release
/platforms/android/build/outputs/apk下就会看到有android-release.apk文件。

cordova-build-android

其实也可以打包出来为签名版本的apk,通过命令行手动加签名,但是对比这个方案就会略显麻烦,建议按照上述这种方式,自动化加上签名。

参考文章Ionic 2 : Building A Release Android APK

官方原文

浏览器环境下使用本地化插件

ionic native拥有130多个移动SDK插件,这点使得可能构建强大的ionic app。

由于历史原因,在浏览器环境下测试这些本地插件是很困难的,要求ionic开发者比如在物理设备或者虚拟机中进行测试,这是相当慢的一个过程。

ionic native3.0现在允许开发者能够伪装,在浏览器环境下通过重写类,是的能够提供测试数据,或者访问本地化API,比如HealthKit。

这意味着大量的ionic app能够不必部署到真机或者模拟器,就可以在浏览器环境下完全的构建了。一流的开发速度,闻所未闻。

伪装插件

为了在浏览器环境下去使用ionic本地化插件,你只需要拓展这些传统插件类和重写一些函数。

让我们伪装下Camera插件返回一张图片吧。

首先在根模块导入Camera类.

1
import { Camera } from '@ionic-native/camera';

然后创建类,拓展Camera类,伪装一个实现。

1
2
3
4
providers: [
{ provide: Camera, useClass: CameraMock }
]

下面是完整的例子

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
import { NgModule, ErrorHandler } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { IonicApp, IonicModule, IonicErrorHandler } from 'ionic-angular';
import { MyApp } from './app.component';
import { HomePage } from '../pages/home/home';

import { Camera } from '@ionic-native/camera';

class CameraMock extends Camera {
getPicture(options) {
return new Promise((resolve, reject) => {
resolve("BASE_64_ENCODED_DATA_GOES_HERE");
})
}
}

@NgModule({
declarations: [
MyApp,
HomePage
],
imports: [
BrowserModule,
IonicModule.forRoot(MyApp)
],
bootstrap: [IonicApp],
entryComponents: [
MyApp,
HomePage
],
providers: [
{provide: ErrorHandler, useClass: IonicErrorHandler},
{ provide: Camera, useClass: CameraMock }
]
})
export class AppModule {}

英文原版
大家好,很高兴的宣布,ionic cli v3版现在可以使用啦!
自从我们发布CLI v3 Beta版和我们的彩蛋,我们已经见证了众多的早期Beta测试者在他们的ionic项目中成功的使用。这些测试者提供了大量的反馈,当然也有机会中奖。事实上,他们中的许多人几个小时内就找到了其中的彩蛋。尤其最近,当开发者在我们上周举办的编程马拉松中成为了Ionic Jedi Hacksters,我们获得了更多的回馈
(编程马拉松战绩在这里)除了版本改变外,什么使得这个CLI这么特别呢,让我们看下这版CLI的几个关键点吧。

除了版本变化,这版的CLI特殊在哪呢,我们看下以下几个关键点吧:

速度+指南

你可能会留意到这版CLI的安装是如此之快,部分原因是在消除了超过90MB的依赖和成千上万行的旧程序code!如今,当你安装CLI的时候,你会得到更小的空间占用,安装时间也会更短。所以,CLI的速度和表现是我们主要考虑点之一。

另一个考虑点是我们要提供更多的帮助、指南和反馈。大量的命令现在提供所需的交互信息,CLI试图在问题出来时,能够是有用的,有效的。命令帮助已经提升。
仅仅加上--help参数到任意的命令上,就可以得到详细的输入信息和参数信息。我们也提供普通使用的样例信息,比如试下下面的这句命令ionic start --help

插件!

我们对插件的架构使用的不同的方法,之前的CLI提供完成的东西,而如今,我们把非必要的命令拆离出,将这些功能以插件形式存在。这使得,在开发特定功能的项目时候,能够按需添加,并且,核心功能保持很小。

对于CLI-v3的首次发版,有以下4个CLI的官方插件

@ionic/cli-plugin-ionic-angular – 提供有用的构建工具和生成器
@ionic/cli-plugin-ionic1 – ionic1项目的CLI
@ionic/cli-plugin-cordova –对于ionic/cordova项目是重要的
@ionic/cli-plugin-proxy – 代理插件

在Beta测试版时候,一个常见的问题是”为什么命令变了”,比如之前是ionic build,如今是ionic cordova build,我们深感这个是必要的改变,因为我们的开发者正在构建桌面,PWA和其它一些平台的ionic APP,为了去区分这些不同,我们做出了这个清单

开始吧

确认你有Node 6+ 和 npm 3+

卸载旧版CLI,全局安装新的CLI:

1
2
3
npm uninstall -g ionic
npm install -g ionic@latest

在你的ionic项目下,确保你已经有标准的ionic项目结构体。比如ionic info,这个命令将试图校对你的项目类型,和推荐你安装需要的插件。如果你运行ionic cordova,将提示你安装cordova插件,如果你运行ionic --help,你将看到所有命令列表。
对于ionic/cordova app,你需要安装cordova插件(ionic/cli-plugin-cordova)和项目插件(@ionic/cli-plugin-ionic-angular 或 @ionic/cli-plugin-ionic1)。

对于ionic angular:

1
2
npm install --save-dev --save-exact @ionic/cli-plugin-ionic-angular@latest
npm install --save-dev --save-exact @ionic/cli-plugin-cordova@latest

对于ionic 1:

1
2
npm install --save-dev --save-exact @ionic/cli-plugin-ionic1@latest
npm install --save-dev --save-exact @ionic/cli-plugin-cordova@latest

CLI也会偶尔提醒你更新这些插件。

已知的问题

对于已经发布的CLI V3,我们有些事情正在做

  • ionic start 仍然花费很长的时间取下载依赖。(#2231)
  • ionic start 目前还不支持可选性,比如从github仓库,一个zip url或者ionic作者的项目 (#1989)
  • 使用ionic cordova命令修改config.xml有4个空格,对于已存在的APP,会有警告信息。我们写入config.xml是因为资源生成和热启。
  • 对于ionic1,一些gulp hook不能被掉起
  • 在安卓设备上,升级到CLI v3在部署时,不能正确的提取

对于CLI更新的完整清单,请查看CHANGELOG.md,
对于更多文档,请看README.md

有问题?想法?反馈?请在仓库里创建Issue,让我们知道。
感谢所有的Beta测试者,尤其感谢那些在仓库上提出有贡献性的Issue、评论和PR的人。