手機APP中post加密

❶ SAML和OAuth2這兩種SSO協議的區別

SSO是單點登錄的簡稱，常用的SSO的協議有兩種，分別是SAML和OAuth2。本文將會介紹兩種協議的不同之處，從而讓讀者對這兩種協議有更加深入的理解。

SAML的全稱是Security Assertion Markup Language， 是由OASIS制定的一套基於XML格式的開放標准，用在身份提供者（IdP）和服務提供者 (SP)之間交換身份驗證和授權數據。

SAML的一個非常重要的應用就是基於Web的單點登錄（SSO）。

在SAML協議中定義了三個角色，分別是principal：代表主體通常表示人類用戶。identity provider (IdP)身份提供者和service provider (SP)服務提供者。

IdP的作用就是進行身份認證，並且將用戶的認證信息和授權信息傳遞給服務提供者。

SP的作用就是進行用戶認證信息的驗證，並且授權用戶訪問指定的資源信息。

接下來，我們通過一個用SAML進行SSO認證的流程圖，來分析一下SAML是怎麼工作的。

上圖中User Agent就是web瀏覽器悶睜敏，我們看一下如果用戶想請求Service Provider的資源的時候，SAML協議是怎麼處理的。

SP將會對該資源進行相應的安全檢查，如果發現已經有一個有效的安全上下文的話，SP將會跳過2-7步，直接進入第8步。

RelayState是SP維護的一個狀態信息，主要用來防止CSRF攻擊。

其中這個SAMLRequest是用Base64編碼的<samlp:AuthnRequest>，下面是一個samlp:AuthnRequest的例子：

為了安全起見，SAMLRequest還可以使用SP提供的簽名key來進行簽名。

IdP收到這個AuthnRequest請求之後，將會進行安全驗證，如果是合法的AuthnRequest，那麼將會展示登錄界面。

這個form中包含了SAMLResponse信息，SAMLResponse中包含了用戶相關的信息。

同樣的SAMLResponse也是使用Base64進行編碼過的<samlp:Response>。

我們可以看到samlp:Response中包含有saml:Assertion信息。

我們可以看到上面的所有的信息交換都是由前端瀏覽器來完成的，在SP和IdP之間早讓不存在直接的通信。

這種全部由前端來完成信息交換的方式好處就是協議流非常簡單，所有的消息都是簡單的GET或者POST請求。

如果螞枝為了提高安全性，也可以使用引用消息。也就是說IdP返回的不是直接的SAML assertion，而是一個SAML assertion的引用。SP收到這個引用之後，可以從後台再去查詢真實的SAML assertion，從而提高了安全性。

SAML協議是2005年制定的，在制定協議的時候基本上是針對於web應用程序來說的，但是那時候的web應用程序還是比較簡單的，更別提對App的支持。

SAML需要通過HTTP Redect和HTTP POST協議來傳遞用戶信息，並且通常是通過HTML FORM的格式來進行數據的提交的。如果應用程序並不是web應用，比如說是一個手機App應用。

這個手機APP應用的啟動鏈接是 my-photos://authenticate ， 但是手機app可能並不能獲取到Http POST的body內容。他們只能夠通過URL來進行參數的傳遞。

這就意味著，在手機APP中不能夠使用SAML。

當然，要想工作也可以，不過需要進行一些改造。比如通過第三方應用對POST消息進行解析，然後將解析出來的SAMLRequest以URL參數的形式傳遞給APP。

另一種方法就是使用OAuth2.

因為Oauth2是在2012年才產生的。所以並沒有那麼多的使用限制。我們可以在不同的場合中使用OAuth2。

我們先來看一下OAuth2中授權的流程圖：

一般來說OAuth2中有4個角色。

resource owner： 代表的是資源的所有者，可以通過提供用戶名密碼或者其他方式來進行授權。通常來是一個人。

resource server：代表的是最終需要訪問到資源的伺服器。比如github授權之後獲取到的用戶信息。

client： 用來替代resource owner來進行交互的客戶端。

authorization server： 用來進行授權的伺服器，可以生成相應的Access Token。

整個流程是這樣的：

Client向resource owner發起一個授權請求，resource owner輸入相應的認證信息，將authorization grant返回給client。

client再將獲取到的authorization grant請求授權伺服器，並返回access token。

client然後就可以拿著這個access token去請求resource server，最後獲取到受限資源。

OAuth2並沒有指定Resource Server怎麼和Authorization Server進行交互。也沒有規定返回用戶信息的內容和格式。這些都需要實現方自己去決定。

OAuth2默認是在HTTPS環境下工作的，所以並沒有約定信息的加密方式。我們需要自己去實現。

最後，OAuth2是一個授權協議，而不是認證協議。對於這個問題，其實我們可以考慮使用OpenID Connect協議。因為OpenID Connect就是基於OAuth2實現的，並且添加了認證協議。

OpenID Connect簡稱為OIDC，已成為Internet上單點登錄和身份管理的通用標准。 它在OAuth2上構建了一個身份層，是一個基於OAuth2協議的身份認證標准協議。

OAuth2實際上只做了授權，而OpenID Connect在授權的基礎上又加上了認證。

OIDC的優點是：簡單的基於JSON的身份令牌（JWT），並且完全兼容OAuth2協議。

在SAML協議中，SAML token中已經包含了用戶身份信息，但是在OAuth2，在拿到token之後，需要額外再做一次對該token的校驗。

但是另一方面，OAuth2因為需要再做一次認證，所以可以在 Authorization Server 端對token進行無效處理。

做過SSO的應該都聽說過CAS。CAS的全稱是Central Authentication Service，是一個企業級的開源的SSO認證框架。

CAS內部集成了CAS1,2,3，SAML1,2，OAuth2,OpenID和OpenID Connect協議，非常的強大。我們會在後面的文章中介紹CAS的使用。

❷ 問答：android P都更新了哪些功能

Android P的新功能特性集中在了UI、通知體驗、室內定位、圖像存儲幾個方面，解決了之前一直存在的痛點。例如WiFi RTT一定程度上彌補了蜂窩網路在室內環境下的定位問題，HEIC圖像格式則重點解決了存儲容量問題。同時，Android P也在通知豐富度及操作便捷性等功能方面有所增強和提升。

一、WiFi RTT功能——復雜地形精確導航

WiFi RTT功能是Android P新引入的一個功能，從原理上來說與蜂窩網路的定位原理一致，但這個功能極大的彌補了蜂窩網路在室內定位的短板，WiFi RTT將能夠在室內提供高精度的定位，這是蜂窩網路很難做到的。

WiFi RTT是全新的功能，在android.net.wifi包下增加了rtt包，用於存放WiFi RTT相關類和介面。

WiFi RTT的API以WifiRttManager為核心，藉助AP熱點或WiFi，利用RTT原理完成測距，通過三個以上的測距點就能夠准確地定位到設備所在位置。

WiFiRTTManager提供了測距介面，是一個非同步測距操作，根據官方文檔（https://developer.android.com/reference/android/net/wifi/rtt/WifiRttManager.html）說明，其測距介面如下：

void startRanging(RangingRequest request, RangingResultCallback callback, Handler handler);

註：SDK Platforms Android P Preview Revision 1的相關介面定義與此不同，但實際的官方鏡像中介面與此一致，開發者需要更新最新的Android P Preview Revision 2，此版本中Google已經修正該介面。

介面中，RangingRequest通過RangingRequest.Builder構建，RangingRequest.Builder構建出RangingRequest所需要的參數可以通過WiFiManager等系統服務獲取到相關的內容，如List<ScanResult> scanResults = wifiManager.getScanResults();

以下提供一個簡單的測試Demo，以供參考：

private WifiRttManager wifiRttManager;
private WifiManager wifiManager;

@Override
protected void onCreate(Bundle savedInstanceState) {
// ... ...

if(getPackageManager().hasSystemFeature(PackageManager.FEATURE_WIFI_RTT)) {
Object service = this.getApplicationContext().getSystemService(Context.WIFI_RTT_RANGING_SERVICE);
if(service instanceof WifiRttManager) {
wifiRttManager= (WifiRttManager) service;
Log.i(TAG, "Get WifiRttManager Succ.");
}

wifiManager = (WifiManager) this.getApplicationContext().getSystemService(Context.WIFI_SERVICE);

IntentFilter wifiFileter = new IntentFilter();
wifiFileter.addAction(WifiManager.NETWORK_STATE_CHANGED_ACTION);
wifiFileter.addAction(WifiManager.WIFI_STATE_CHANGED_ACTION);
wifiFileter.addAction(WifiManager.SCAN_RESULTS_AVAILABLE_ACTION);
registerReceiver(new WifiChangeReceiver(), wifiFileter);
}

// ... ...
｝

private void startScanAPs() {
wifiManager.setWifiEnabled(true);
wifiManager.startScan();
}

class WifiChangeReceiver extends BroadcastReceiver {
@RequiresApi(api = 28)
@Override
public void onReceive(Context context, Intent intent) {
if (intent.getAction().equals(WifiManager.SCAN_RESULTS_AVAILABLE_ACTION)) {
List<ScanResult> scanResults = wifiManager.getScanResults();
Log.i(TAG, "Wifi Scan size:" + scanResults.size());
for(ScanResult scanResult: scanResults) {
Log.i(TAG, scanResult.toString());
RangingRequest.Builder builder = new RangingRequest.Builder();
builder.addAccessPoint(scanResult);
wifiRttManager.startRanging(builder.build(), new RangingResultCallback() {
@SuppressLint("Override")
@Override
public void onRangingFailure(int i) {
// TODO
}
@SuppressLint("Override")
@Override
public void onRangingResults(List<RangingResult> list) {
// TODO get result from list

for(RangingResult result : list) {
Log.i(TAG, result.toString());
}
}
}, new Handler());
}
}
}
}

使用WiFi RTT時，需要在AndroidManifest.xml中增加如下聲明：

<uses-feature android:name="android.hardware.wifi.rtt" />

通過上面的簡單代碼，就能夠實現WiFi RTT的功能。

WiFi RTT功能適用於復雜地形的大型室內外場所，如商場、娛樂場所、大型休閑、游樂場等等，提供場所內的局部區域精確化導航等功能。相信在很快的時間內，就能夠在各大地圖應用內體驗到這項便利功能，對於路痴、地圖盲的夥伴們將是極大的福音。

二、顯示剪切——支持劉海屏

隨著iPhone X的推出，「劉海屏」達到了空前的高潮。Android P里提供了對異形屏幕的UI適配兼容方案，通過DisplayCutout類提供的相關介面，能夠獲取到屏幕中Cutout區域的信息。

藉助DisplayCutout，可以獲取到如下信息：

DisplayCutout displayCutout = view.getRootWindowInsets().getDisplayCutout();
if(displayCutout != null) {
Region bounds = displayCutout.getBounds();
Log.d(TAG, String.format("Bounds:%s", bounds.toString()));
int top = displayCutout.getSafeInsetTop();
int bottom = displayCutout.getSafeInsetBottom();
int left = displayCutout.getSafeInsetLeft();
int right = displayCutout.getSafeInsetRight();
Log.d(TAG, String.format("Cutout edge:[left:%d, top:%d,right:%d, bottom:%d]", left, top, right, bottom));
}

public Region getBounds()能夠獲取到Cutout區域的所有信息，Region就是Cutout區域。

public int getSafeInsetTop()
public int getSafeInsetBottom()
public int getSafeInsetLeft()
public int getSafeInsetRight()

以上四個介面，可以獲取到去除Cutout區域後的安全區域邊界值。

通過上述數據，開發者能夠精準的控制UI的繪制，避免將UI內容繪制到Cutout區域造成UI顯示異常。

Android機器里，劉海屏目前還是極為罕見的Google為了方便開發者調試，在Android P Preview鏡像中，特別提供了Cutout的支持，具體打開方式可以參考Google提供的特性說明文檔cutout小節內容。

cutout小節：https://developer.android.com/preview/features.html#cutout

如圖所示，筆者使用手頭的Pixel 2 XL體驗了Android P的Cutout設置。

三、通知優化——操作更多樣，內容更豐富

Android P在通知內容的豐富度和操作上做了優化。

最近的版本中，Android系統的通知管理方面一直優化升級，Android O提供了更細粒度的Channel功能，通知欄推送時需要指定NotificationChannel，用戶可以對通知的Channel選擇，只允許感興趣的Channel推送的通知顯示。通過通道設置、免打擾優化等方式，極大增強了消息體驗。

增強消息體驗

Android P繼續改進和增強消息通知[v1]。早在Android 7.0時，就提供了在通知中直接應答和輸入，Android P對這一功能做了更多的增強。

Android P的通知中支持圖像內容，可以通過setData()方法，給出消息的圖像內容，在通知上展示給用戶。

Android P同樣簡化了通知的配置形式。Android P中增加了Notification.Person類，用於區分同一個對話的參與者信息，如參與者的頭像、URI等。根據官方說明，Android P中，通知消息的其他一些API，也使用Person替代之前的CharSequence。

簡單的體驗下新的API的開發：

NotificationChannel channel = new NotificationChannel("WtTestChannel",
"WtTestChannel", NotificationManager.IMPORTANCE_DEFAULT);
channel.enableLights(true); // luncher icon right corner's point
channel.setLightColor(Color.RED); // read point
channel.setShowBadge(true); // whether show this channel notification on long press icon

Notification.Builder builder =
new Notification.Builder(MainActivity.this,
"WtTestChannel");
Notification.Person p = new Notification.Person();
p.setName("WeTest");
p.setUri("http://cdn.wetest.qq.com/" +
"ui/1.2.0/pc/static/image/newLogo-16042.png");
Notification.MessagingStyle messageStyle = new Notification.MessagingStyle(p);
Notification.MessagingStyle.Message message =
new Notification.MessagingStyle.Message("WeTestMessage", 2000, p);

//show image
Uri image = Uri.parse(
"http://cdn.wetest.qq.com/ui/1.2.0/pc/static/image/newLogo-16042.png");
message.setData("image/png", image);
messageStyle.addMessage(message);
builder.setStyle(messageStyle);
builder.setSmallIcon(R.mipmap.ic_launcher);
Notification notification = builder.build();

NotificationManager notifyManager =
(NotificationManager) getSystemService(
MainActivity.this.getApplicationContext().NOTIFICATION_SERVICE);


notifyManager.createNotificationChannel(channel);
notifyManager.notify("WeTest", 1, notification);

通道設置、廣播和免打擾優化

Android P中，重點做了內容豐富上的工作，同時也對Channel的設置方面做了一些簡化處理。

Android O版本里，首次推出了NotificationChannel，開發者需要配置相應的Channel，才能夠推送通知給用戶。用戶能夠更加細粒度[v1]的針對App的Channel選擇，而不是禁止App的所有通知內容。

而在Android P中，對通知的管理做了進一步的優化，包括可以屏蔽通道組、提供新的廣播類型和新的免打擾優先順序。

屏蔽通道組：用戶可以在通知設置中屏蔽App的整個通道組。開發者可以通過isBlocked()來判斷某個通道組是否被屏蔽了，並根據結果，不向已經被屏蔽的通道組發送任何通知。另外，開發者可以在App中使用新介面getNotificationChannelGroup()來查詢當前的通道組設置。

新的廣播類型：新廣播類型是針對通道和通道組的功能增加的「通道(組)屏蔽狀態變化」廣播。開發者App中可以對所擁有的通道(組)接收廣播，並根據具體廣播內容作出動作。開發者可以通過NotificationManager，查看廣播相關的具體信息。針對廣播的動作可以通過Broadcasts查看具體的方法和信息。

免打擾優先順序：NotificationManager.Policy增加了兩個新的優先順序常量，PRIORITY_CATEGORY_ALARMS(警告優先)，PRIORITY_CATEGORY_MEDIA_SYSTEM_OTHER(媒體、系統和游戲聲音優先)。

四、支持多攝像機和相機共享

近一段時間，雙攝、多攝等機型紛紛面世。雙攝及多攝提供了單攝像頭所無法完成的能力，如無縫縮放、散景和立體視覺。Android P在這方面也提供了系統級的API支持。

Android P提供了系統API，支持從兩個或者多個物理攝像頭同步獲取數據流。此前OEM廠商提供的雙攝設備多是廠商自行定製系統實現，此時Android P推出了API，從系統層面上制定了API規范。

新的API提供了在不同相機之間切換邏輯數據流或混合數據流的調用能力。在捕捉延遲方面，提供新的會話參數，降低初始捕捉延遲。同時，提供相機共享能力，以解決在多種使用相機的場景下重復停止、開啟相機流。閃光燈方面，Android P增加基於顯示的閃光燈支持。光學防抖方面，Android P向開發者提供OIS時間戳，用於圖像穩定性優化以及其他特效使用。

此外，Android P還支持外部USB/UVC相機，可以使用更強大的外置攝像頭模組。

五、支持圖像媒體後期處理

Android P引入了新的ImageDecoder，該類除了支持對各種圖片格式的解碼、縮放、裁剪之外，其強大之處在於支持對解碼後的圖像做後期處理（post-process)，使用該功能可以添加復雜的自定義特效，比如圓角，或是將圖片放在圓形像框中。編寫後期處理回調函數，你可以添加任何繪圖指令實現需要的效果。

此外，Android P原生支持GIF和WebP格式的動圖，新增了AnimatedImageDrawable類，並被新增的解碼器類ImageDecoder直接支持，用法跟矢量動畫類AnimatedVectorDrawable類似，實現方式也類似，通過新增渲染線程和工作線程，不需要在UI線程處理動圖更新，可以說是無痛使用，非常省心。

下面通過編寫代碼，顯示一張gif圖，並利用後期處理機制，在圖像中間繪制一個綠色的實心圓。

final ImageView image = (ImageView) findViewById(R.id.image);
File gifFile = new File("/data/local/tmp/test.gif");
if (!gifFile.exists()) {
Log.d(TAG, "gifFile is not exsited!");
return;
}

ImageDecoder.Source source = ImageDecoder.createSource(gifFile);
try {
d = ImageDecoder.decodeDrawable(source, new ImageDecoder.OnHeaderDecodedListener() {
@Override
public void onHeaderDecoded(ImageDecoder imageDecoder, final ImageDecoder.ImageInfo imageInfo, ImageDecoder.Source source) {
imageDecoder.setPostProcessor(new PostProcessor() {
@Override
public int onPostProcess(Canvas canvas) {
int w = imageInfo.getSize().getWidth();
int h = imageInfo.getSize().getHeight();
Paint paint = new Paint();
paint.setAntiAlias(true);
paint.setColor(Color.GREEN);
canvas.drawCircle(w/2, h/2, h/4, new Paint(paint));
return 0;
}
});
}
});
image.setVisibility(View.VISIBLE);
image.setImageDrawable(d);
} catch (IOException e){
Log.d(TAG, e.toString());
}
Button button = (Button) findViewById(R.id.buttonText);
button.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View view) {
if (d != null && d instanceof AnimatedImageDrawable) {
AnimatedImageDrawable ad = (AnimatedImageDrawable) d;
if (ad.isRunning()) {
Log.d(TAG, "stop running");
ad.stop();
} else {
Log.d(TAG, "start running");
ad.start();
}
}
}
});

六、支持HDR VP9和HEIF

Android P內置了對HDR VP9和HEIF(heic)圖像編碼的支持。HEIF是蘋果在iOS11推出的一種高效壓縮格式，目前在IphoneX、Iphone 8、IPhone 8P上已經支持。該格式的壓縮率更高，但是編碼該格式需要硬體的支持，解碼並不需要。最新的支持庫中的HeifWriter支持從YUV位元組緩沖區、Surface或是Bitmap類轉換為HEIF格式的靜態圖像。

Android P新引入了MediaPlayer2，支持DataSourceDesc創建的播放列表。

功能優化提升一覽

一、神經網路API 1.1

在前不久發布的Android 8.1 (API level 27)上，Google首次在Android平台上推出了神經網路API，這意味著我們的Android機器智能化水平又提高了一大步。而本次Android P，進一步豐富了神經網路的支持，不僅對之前的相關API進行了優化，並且提供了9個新的操作，為具體的數據操作方面提供了更深入的支持。

二、改進表單自動填充

Android 8.0（API等級26）中引入了自動填充框架，這使得在應用中填寫表單變得更加容易。 Android P引入了自動填充服務並實現了多項改進，得以在填寫表單時進一步增強用戶體驗。

三、安全增強

Android P引入了許多新的安全功能，包括統一的指紋驗證對話框和敏感交易的高確信度的用戶確認。應用程序內的指紋認證UI也將會更加一致。

統一的指紋驗證對話框

如果第三方APP想要使用指紋，Android系統框架為應用提供了指紋認證對話框，該功能可以提供統一的外觀和使用體驗，用戶使用起來更放心。如果您的程序還在使用FingerprintManager，現在改用FingerprintDialog替代吧，系統來提供對話框顯示。對了，在使用FingerprintDialog之前，別忘了調用hasSystemFeature()方法檢查手機設備是否支持指紋。

敏感交易的高確信度的用戶確認

Android P系統提供了受保護的確認API，藉助這組全新的API，應用可以使用ConfirmationDialog對話框向用戶提示，請求用戶批准一條簡短的聲明， 該聲明允許應用提醒用戶，即將完成一筆敏感交易，例如支付。

如果用戶接受聲明，應用將會收到一條key-hash的消息認證碼（HMAC)，該簽名由TEE產生，以保護用於輸入和認證對話框的顯示。該簽名表示用於已經看到了聲明並同意了。

硬體安全模塊

Android P還提供了StrongBox Keymaster（強力沙盒秘鑰大師），一個存儲在硬體安全模塊的具體實現。在這個硬體安全模塊中有自己的CPU、安全存儲空間，真隨機數生成器，以及額外的機制抵禦應用被篡改或是未授權應用的惡意載入。當檢查存儲在StrongBox Keymaster中的密鑰時，系統通過可信執行環境（TEE）確認密鑰的完整性。為了降低能耗，StrongBox支持了一組演算法和不同長度的秘鑰：

●RSA 2048

●AES 128 and 256

●ECDSA P-256

●HMAC-SHA256 (支持8位元組到64位元組任意秘鑰長度)

●Triple DES 168

需要說明的是，這個機制需要硬體支持。

安全秘鑰導入KeyStore

使用新的ASN.1編碼的秘鑰格式添加導入秘鑰到Keystore，Android P提供了額外的密碼解密安全能力。之後KeyMaster就可以解密KeyStore存儲的秘鑰，這種工作方式使得秘鑰明文永遠不會出現在設備內存中。這項特性要求設備支持Keymaster 4。

四、支持客戶端側Android備份加密

Android P支持使用客戶端密鑰對Android備份進行加密。 這項隱私措施，需要設備的PIN、圖案密碼或標准密碼才能從用戶設備備份的數據中恢復數據。

五、Accessibility優化

為了使App使用更便捷，Android在多個方面為開發者提供了易用性的優化。

1、Navigation semantics

Android P在App的場景切換和操作上為開發者提供了很多的優化點。

2、Accessibility pane titles

Android P中對Section提供了新的機制，被稱為accessibility pane titles， Accessibility services能夠接收這些標題的變化，使得能夠對一些變化提供更加細粒度的信息。

指定Section的標題，可以通過android:accessibilityPaneTitle新屬性來設置，同樣運行時可以通過setAccessibilityPaneTitle()來設置標題。

3、頂部欄導航

Android P提供了新的頂部欄導航機制，通過設置View實例的android:accessibilityHeading屬性為true,來顯示邏輯標題。通過這些標題，用戶就可以從一個標題導航到下一個標題，

4、群組導航和輸出

針對屏幕閱讀器，Android P對View提供了新的屬性android:screenReaderFocusable代替原有的android:focusable來做標記，來解決在一些場景下為了使屏幕閱讀器工作而設置View為可獲取焦點的操作。這時，屏幕閱讀器需要同時關注android:screenReaderFocusable和android:focusable設置為ture的View。

5、便捷操作

tooltips交互

Android P中，可以使用getTooltipText()去讀取tooltips的文本內容。使用新的ACTION_SHOW_TOOLTIP和ACTION_HIDE_TOOLTIP控制View顯示或者隱藏tooltips。

新全局交互

Android P在AccessibilityService類中提供了兩個全新的操作。開發者的Service可以通過GLOBAL_ACTION_LOCK_SCREEN幫助用戶鎖屏，通過GLOBAL_ACTION_TAKE_SCREENSHOT幫助用戶完成屏幕截圖。

窗體改變的一些細節

Android P優化了在App多窗體同步發生變化時的更新內容獲取。當出現TYPE_WINDOWS_CHANGED時，開發者可以通過getWindowChanges()API獲取窗體變化情況。

當多窗體發生改變時，每個窗體都會發出自己的事件，開發者可以通過getSource()獲取到事件窗體的根View。

如果你的App為View定義了accessibility pane titles，UI更新時你的Service就能夠識別到相應的改動。當出現TYPE_WINDOW_STATE_CHANGED事件時，使用新方法 getContentChangeTypes()返回的類型，就能夠獲取到當前窗體的變化情況。例如，現在就能夠通過上述的機制，檢測到一個[v1]窗格是否有了新標題，或者一個窗格的消失。

六、新的Rotation方案

旋轉屏幕，是一些游戲、視頻等場景必要的操作，但有一些場景，用戶旋轉屏幕並不是為了讓應用顯示從豎屏變成橫屏或反過來。為了避免這種誤操作，Android P提供了新的機制，開發者可以指定屏幕不隨重力感應旋轉，而是用戶通過一個單獨的按鈕自行控制屏幕顯示轉向。

❸ java給別人提供介面，介面安全怎麼保證

我們在開發過程中，肯定會有和第三方或者app端的介面調用。在調用的時候，下面的方法可以來防止非法鏈接或者惡意攻擊。

一、簽名

根據用戶名或者用戶id，結合用戶的ip或者設備號，生成一個token。在請求後台，後台獲取http的head中的token，校驗是否合法（和資料庫或者Redis中記錄的是否一致，在登錄或者初始化的時候，存入資料庫/redis）

在使用Base64方式的編碼後，Token字元串還是有20多位，有的時候還是嫌它長了。由於GUID本身就有128bit，在要求有良好的可讀性的前提下，很難進一步改進了。那我們如何產生更短的字元串呢？還有一種方式就是較少Token的長度，不用GUID，而採用一定長度的隨機數，例如64bit，再用Base64編碼表示：

varrnd =newRandom();
vartokenData =userIp+userId;
rnd.NextBytes(tokenData);
vartoken =Convert.ToBase64String(tokenData).TrimEnd('=');

由於這里只用了64bit，此時得到的字元串為Onh0h95n7nw的形式，長度要短一半。這樣就方便攜帶多了。但是這種方式是沒有唯一性保證的。不過用來作為身份認證的方式還是可以的（如網盤的提取碼）。

二、加密

客戶端和伺服器都保存一個秘鑰，每次傳輸都加密，服務端根據秘鑰解密。

客戶端：

1、設置一個key（和伺服器端相同）

2、根據上述key對請求進行某種加密（加密必須是可逆的，以便伺服器端解密）

3、發送請求給伺服器

伺服器端：

1、設置一個key

2、根據上述的key對請求進行解密（校驗成功就是「信任」的客戶端發來的數據，否則拒絕響應）

3、處理業務邏輯並產生結果

4、將結果反饋給客戶端

三、第三方支持

比如springsecurity－oauth

❹ auth返回狀態碼異常

throw new AuthException("ssCode","登錄錯了");
返回：
{
"error" : "ssCode",
"error_description" : "登錄錯了"
}
文章知識點與官方知識檔案匹配
Java技能樹首頁概覽
86213 人正在系統學習中
打開CSDN，閱讀體驗更佳
springsecurity+oauth2+jwt實現單點吵備冊登錄demo
該資源是springsecurity+oauth2+jwt實現的單點登錄demo，模式為授權碼模式，實現自定義登錄頁面和自定義授權頁面。應用數據存在內存中或者存在資料庫中（附帶資料庫表結構），token存儲分為資料庫或者Redis。demo包含服務端和客戶端，可直接運行測試。
Spring Security OAuth2 認證伺服器自定義異常處理
認證伺服器默認返回的數據格式如下： { "error": "unsupported_grant_type", "error_description": "Unsupported grant type: password1" } 上面的返回結果很不友好，而且前端代碼也很難判斷是什麼錯誤，所以我們需要對返回的錯誤進行統一的異常處理 1.默認的異常處理器 默認情況是使用WebRespo...
繼續訪問
自定義spring security oauth /auth/token的返回內容格式
場景 在前後端分離的項目中，一般後端返回給前端的格式是一個固定的json格式。 在這個前提下，spring security oauth 生成access token的請求/auth/token的返回內容就需要自定義 原返回值 我們希望使用我們自己固定的json格式 需求 我們的BaseResponse類 public class BaseResponse { pri...
繼續訪問
Spring Security OAuth2模塊/oauth/token授權介面自定義返回結果
spring security提供了默認的oauth登錄授權升宏介面/oauth/token，該介面位於org.springframework.security.oauth2.provider.endpoint包中的TokenEndpoint類。 公司要實現自定義的登錄授權介面，且返回值滾型也要實現私有結構，下面大概講一下怎麼改造這個類來實現要求的業務邏輯。 一、利用Spring AOP方式 二、自定義Controller介面實現 簡單粗暴，直接把TokenEndpointer類注入到自定義Controller中；
繼續訪問
Spring Security Oauth2 自定義異常返回信息
開頭引用 https://my.oschina.net/merryyou/blog/1819572 在使用Spring Security Oauth2登錄和鑒權失敗時，默認返回的異常信息如下 { "error": "unauthorized", "error_description": "Full authentication is required to access this r...
繼續訪問
oauth2.0源碼分析之oauth/token申請令牌
本期介紹的是在oauth2.0中 , 通過調用oauth/token介面 , 框架是如何給我們申請到JWT令牌的 , 內部做了些什麼事情 ? 在分析源碼之前 , 我們首先需要知道的是我們需要具備哪些調試條件 , 不然會發現許多奇奇怪怪的錯誤 (比如通過/oauth/token時出現401) 1.一張oauth2.0的內置表(oauth_client_details) 注意:這里的密碼需要用Bcript加密 , 因為源碼內部是用Bcript解密的 2.兩把鑰匙: 一本是後綴為jks的私鑰 另一本是後綴為k
繼續訪問
SpringSecurity+OAuth2認證/oauth/token登錄報錯There is no client authentication
報錯信息： { "error": "unauthorized", "error_description": "There is no client authentication. Try adding an appropriate authentication filter." } 找到這個問題原因後，發現自己被自己蠢哭了。 在自己的核心配置類里，把這個/oauth/token加入到忽...
繼續訪問
spring security+Oauth2密碼模式認證時，報401，Unauthorized的問題排查
第一種情況： 進行 /auth/token的post請求時，沒有進行httpbasic認證。 什麼是http Basic認證？ http協議的一種認證方式，將客戶端id和客戶端密碼按照「客戶端ID:客戶端密碼」的格式拼接，並用base64編碼，放在 header中請求服務端。例子如下： Authorization：Basic ASDLKFALDSFAJSLDFKLASD= ASDLKFALDSFAJSLDFKLASD= 就是 客戶端ID:客戶端密碼 的64編碼 springsecurity中的...
繼續訪問
最新發布 SpringBoot使用SpringSecurity,使用oauth2登錄,使用自定義/uaa/oauth/token報錯解決
SpringBoot使用SpringSecurity,使用oauth2登錄,使用自定義/uaa/oauth/token報錯解決
繼續訪問
asp.net WebAPI OWIN OAuth2.0授權自定義返回結果及錯誤或異常問題處理辦法
asp.net WebAPI OWIN OAuth2.0授權自定義返回結果及錯誤或異常問題處理核心代碼,詳情： https://www.cnblogs.com/wgx0428/p/12315546.html
ASP.NET WebAPI Token JWT Bearer 認證失敗和成功返回自定義數據 Json
asp.net WebAPI Token Oauth2.0授權自定義返回結果(包括登錄正確返回，登錄失敗返回)。 詳細參考：https://blog.csdn.net/u013546115/article/details/105580532
Spring Security OAuth2 token許可權隔離實例解析
主要介紹了Spring Security OAuth2 token許可權隔離實例解析,文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值,需要的朋友可以參考下
spring security oauth其中的/oauth/token做了哪些
項目場景： 問題描述： 提示：這里描述項目中遇到的問題： 例如：數據傳輸過程中數據不時出現丟失的情況，偶爾會丟失一部分數據 APP 中接收數據代碼： 原因分析： 提示：這里填寫問題的分析： 例如：Handler 發送消息有兩種方式，分別是 Handler.obtainMessage()和 Handler.sendMessage()，其中 obtainMessage 方式當數據量過大時，由於 MessageQuene 大小也有限，所以當 message 處理不及時時，會造成先傳的數據被覆蓋，進而.
繼續訪問
Spring Security OAuth2 自定義 token Exception
https://raw.githubusercontent.com/longfeizheng/longfeizheng.github.io/master/images/spring-security-OAuth208.png 1. 前言 在使用Spring Security Oauth2登錄和鑒權失敗時，默認返回的異常信息如下 { "error": "unauthorized", "error_description": "Full authentication is required to
繼續訪問
前後端分離 token過期 返回狀態碼
1.首先配置Mvc配置文件類 @Configuration public class BackendConfiguration extends WebMvcConfigurationSupport { @Autowired private LoginInterceptor loginInterceptor; @Override public void addInterceptors(InterceptorRegistry registry) { regi
繼續訪問
SpringSecurityOAuth2(2)請求攜帶客戶端信息校驗，自定義異常返回，無權處理，token失效處理...
上文地址：SpringSecurityOAuth2(1)（password,authorization_code,refresh_token,client_credentials）獲取token 上一篇博客寫了一個至簡的OAuth2的token認證伺服器，只實現了4種獲取token的方式 ,對...
繼續訪問
oauth2.0自定義token失效返回信息
oauth2.0自定義token失效返回信息 一、問題 由於spring security oauth2返回的失效信息對於客戶端不太有好，在網上找了自定義的解決方案以便更優雅的展示返回信息。 重寫框架里的方法，實現自定義。 二、配置類 Oauth2ResourceServer extends @Override public void configure( reso
繼續訪問
熱門推薦 解決Spring Security OAuth在訪問/oauth/token時候報401 authentication is required
先來張圖片 我在用psotman 測試oauth授權碼模式的出現了401的異常， 就是調用oauth/token. 我是想用code換token，但是發現報錯了。這是為什麼呢？ 首先你要理解 /oauth/token 這個如果配置支持的，且url中有client_...
繼續訪問
spring security 和OAuth2 整合訪問 localhost:8082/oauth/token 報401的問題,或者403的問題
@Bean public PasswordEncoder passwordEncoder() { /** * 采坑 * spring-boot2 之後廢棄了MD5,使用BCryptPasswordEncoder()加密; * */ return new BCryptPasswordEncoder(); } 注意在security的配置內中,要使用BCryptPasswordEncoder 加密,..
繼續訪問
資料庫課程設計
c語言文件讀寫操作代碼
html+css+js網頁設計

❺ 分析安卓app的post數據 用什麼抓包軟體比較好

360手機助手最好用，其次網路手機助手，qq手機助手都還可以。豌豆莢做的確實不好，現在還是改良版的，以前的更爛。