Giftpack

giftpack

They left in droves. Over quit their jobs in 2021. The mass exodus of workers accelerated last year and shows no signs of slowing down in 2022. While this trend might look bad for the job market, it’s good news for technological development. 40 million employees The Great Resignation is already fast-forwarding mass adaption of AI, both to support current employees and to compensate for the ongoing labor shortage. Analysts predict a boom in the industrial robotics sector, from $16 billion to $37 billion over the next 10 years. projected to grow , an exchange-traded fund focusing on bots in business, more than doubled its 10-year growth forecast, citing 2022 as “that key inflection point.” Global X’s Robotics AI-based solutions already respond to calls, provide customer service, operate as cashiers, and assist HR departments in their hiring processes. But future applications of AI technology will include more than just basic tasks. For example, AI could anticipate when an employee is preparing to hand in their two weeks’ notice. Most importantly, it might help establish why they chose to leave. Thanks to digital footprints — records of online activity, unique as fingerprints — AI-powered HR tools can engage their employees with personalized recommendations. Several startups are doing just that. One such startup is the AI-based solution which set out to transform gifting, now an important part of corporate benefit strategies. , Giftpack For example, if the gift recipient posts Instagram pictures of snowboarding trips and browses winter sports gear sites, they might get some custom accessories. The company's own AI solution finds gifts from a catalog of over 3 million products available worldwide. By analyzing the gift recipient's digital footprint, the service can get a sense of their interests and suggest a range of suitable options. In the pandemic, companies more than their spending on presents for employees. The average check also increased by almost 70% last year, averaging at around $140 per unit year-over-year. doubled AI can help large companies eliminate a “one-size-fits-all” approach to their workers, and not just when it comes to gifting. Most businesses don’t know who their employees are, especially if they’re working remotely. What are their interests, hobbies, aspirations? What really motivates them — what makes them get up in the morning? If HR departments have enough data, and, most importantly, AI-based recommendations, they could foster new career opportunities within their organizations. Nestle, Novartis, Unilever, HSBC, and other companies already implemented an internal talent marketplace in cooperation with , the future of work startup. The project works with employees to build new skills and try out new roles on a part-time basis. Gloat Mental health and burnout pose another major issue: 46% people planning to quit their jobs listed work stress as top reason. AI-based solutions could help HR departments assess employee satisfaction and provide better support to those who need it. According to HR tech influencer Tyrone Smith, analytic tools promoting active listening and predictive responses can highlight potential trouble, assisting HR staff on a day-to-day basis. The present moment — with businesses in existential crisis and workers walking out en masse — could be the moment when AI-based HR tools are adopted on a large scale. The work crisis has brought with it a sense of urgency. After The Great Resignation, we might well see the great AI-driven workplace transformation.

The Great Resignation is Happening Fast. How can AI help? 

Github being hacked? To most that doesn’t sound too unreasonable as major tech companies and minor ones have been hacked before. However, this doesn’t mean the likely hood of Github being hacked is high. Why is that? Github is the main open code repository for all in the IT industry. Regardless of sub-sector. Even if someone does Embedded systems, Web3 development, Web2 development, Data science etc most would use Github to store their code. It is because of this that Github’s security has always been so extremely high. Not just because they wanted to be trusted by their users but also because the code on their users’ Github repositories is filled with crypto private keys, API private keys, financial credentials and even proprietary software of multiple companies across the IT industry globally. It is for this reason that Github has always been hard-handed with its security and user accessibility, that is why their hacking, although not completely surprising, is very startling and worrying. Context of the Githack: It is a malware attack. So not a traditional DDoS or forced penetration attack one would have expected, but potentially more lethal. The hacker/hackers uploaded a widespread piece of Malware to different repositories across the platform. What type of hack attack was it? it copies any financial information, authentication information and private crypto keys, essentially the ENV of the script. Then when accepted into the repository and ran locally on the then affected computers, it will copy and send the information to the attacker. So not a hack in a traditional sense but definitely a hack as information was still extracted through non-consensual data breach means. What does the Malware do? this particular attempted hack has reached no more and no less than 35,000 Github repositories. It has infiltrated repositories such as the python repo, golang repo, docker repo and bash repo. Some of the repositories affected were even archived and unused. Some were even seen with the malware inside of them from as far back as 2015. This indicates that the hack was a well-documented and planned one. What is the breadth of the hack attack? It is added to the Github repositories through a commit and in the commit through npm scripts or different docker image classifications. So you would, mainly, only be vulnerable if your project utilized javascript in some way or docker. Then if the commit is accepted and is cloned and used in the main repository, the users who cloned it will be affected. How does it infiltrate the Github repositories? How to prevent this? As I type about this incident all parties involved in the cleanup, the repository owners and Github, are already in the process of damage control and making sure this doesn’t happen again. We can speculate and wonder as to what the different security techniques and defenses Github will use to protect themselves from future attacks. As such we must focus on us as individuals or groups. What can we do in our own capacity to stop future data theft like this? only I know this might be harder for most large open source projects. However, be cautious when accepting push requests, Especially if the push requests edit the environmental variables of your application. Don’t accept push requests from random people to your repository. I know most of us actively don’t do this. Simply because repositories contain so many files and folders that keeping track of them and analyzing them one by one will be tiring. So it would be wise to check the most important files such as the readme and .env files. Always check what exactly you are cloning from a git repository. Github actually has a security framework, driven by Githook, that allows you to send HTTP post requests when certain events are met during the push request. There are different technologies that can analyze your push or pull request for security vulnerabilities, common viruses and other types of security breaches in your code. Use security testing in push requests. Overall let this be a lesson to us all. The attacks that nefarious organizations/people may do are not just rudimentary but also advanced and very unconditional as well as long-term planned. As developers we need to be more aware of the vulnerabilities of our code, repositories, computers and even ourselves and that if someone wants information they can find very different ways to get it. Even if the internet should be safe, doesn’t mean it is. It is up to everyone to do their part to make your own data safe, and if you can, find ways to help others keep their data safe. For a further reading on the situation go here: https://www.bleepingcomputer.com/news/security/35-000-code-repos-not-hacked-but-clones-flood-github-to-serve-malware/

GitHACK! We are the vulnerability

GitHACK! Somos la vulnerabilidad

GitHACK ! Nous sommes la vulnérabilité

गिटहैक! हम भेद्यता हैं

ギットハック！私たちは脆弱性です

GitHACK! Nós somos a vulnerabilidade

GitHACK! Chúng tôi là lỗ hổng

吉哈克！我们是漏洞

187 Stories To Learn About Microsoft

This post is about open-sourcing modules from a private . It’s a hard problem with a decent number of gotchas. We want to share our experience wiring this up to help others who venture down the same path. monorepo How we structure our monorepo A bit of context about Dopt before we dive in: Dopt is a web application for designing user-state machines on a canvas, paired with APIs and SDKs for utilizing those machines at runtime. The idea is that you can instantiate these machines per user of your product. We let you progress the user through the machine and handle the persistence of the user’s state in each machine for you. You can iterate on and version your machines, and we’ll handle migrating your users across machines’ versions. This should be deep enough to contextualize any Dopt-specific bits in this article (but if you’re interested in diving deeper, you can check out our ). docs We develop in a monorepo at Dopt. Our monorepo is home to the apps that live on dopt.com and the packages/services they share. It’s the source of truth for all things Dopt. We use and at Dopt. The defines the root of our workspace and allows us to define/constrain where packages can live in the monorepo. pnpm pnpm workspaces pnpm-workspace.yaml It looks something like this: packages:
  - "apps/**/*"
  - "packages/**/*"
  - "apis/**/*"
  - "services/**/*" Our monorepo's structure is app-centric in nature, e.g., we are building products as opposed to reusable libraries. This is reflected in our folder structure: ├── apps          (apps that live on dopt.com)
├── services      (internal services used by app(s) and API(s))
├── apis          (public APIs hosted on dopt subdomains)
└── packages      (packages shared by apps, services, and APIs) Children directories in these folders correspond to package scopes e.g. ├── apps
│   ├── @app
│   ├── @www
│   ├── @blog
│   └── @docs
├── services
│   ├── @gateway
│   └── @transitions
├── apis
│   ├── @users
│   └── @blocks
└── packages
    ├── @bodo
    └── @dopt and their children correspond to packages themselves ├── apps
│   ├── @app
│   ├─────── client
│   ├─────── server
│   ├─────── database
│   ├── @www
│   ├─────── app
│   ├── @blog
│   ├─────── app
│   ├── @docs
│   └─────── app
├── services
│   ├── @gateway
│   ├─────── service
│   ├─────── definition
│   ├── @transitions
│   ├─────── service
│   └─────── definition
├── apis
│   ├── @users
│   ├─────── service
│   ├─────── definition
│   ├── @blocks
│   ├─────── service
│   └─────── definition
└── packages
    ├── @bodo
    ├─────── alert
    ├─────── box
    ├─────── ...
    ├── @dopt
    ├─────── app-client-sdk
    ├─────── app-middleware
    ├─────── block-client-sdk
    └─────── ... Scopes in the directory corresponds directly to apps on subdomains of dopt.com app └─── apps
   ├── @app         (app.dopt.com)
   ├── @www         (www.dopt.com)
   ├── @blog        (blog.dopt.com)
   └── @docs        (docs.dopt.com) Scopes in the directory correspond Public APIs hosted on subdomains of apis dopt └─── apis
   ├── @blocks        (blocks.dopt.com)
   └── @users         (users.dopt.com) Problem: open sourcing from a private monorepo means filtering and syncing commits The directory is home to services that power our public APIs. These are the APIs folks use to drive our user-state machines. apis There are really three ways to use said APIs: Directly (e.g. , , or some other language-specific tool for making HTTP requests) curl fetch API Clients (i.e., generated language-specific abstractions for talking to our REST API) SDKs (i.e., framework-specific libraries that go beyond basic REST requests, e.g., they create socket connections). For API clients and , we need to get that code into folks’ hands. That means publishing already built versions of those packages to language-specific registries (e.g., npm, pip, etc.) for usage in their codebase and open-sourcing the raw, uncompiled source so folks can peruse, build, debug, contribute, and file issues. SDKs Packages in a monorepo can depend on other packages in a monorepo. This is the benefit of a monorepo, e.g., you can easily create reusable/shareable code by extracting things out into their own modules. Open-sourcing a package from a monorepo means open-sourcing everything that the package depends on as well. This concept is likely intuitive, but it’s worth pointing out a few implications of this that are perhaps less intuitive. The open-source repository will itself need to be a monorepo Any change to an open-source package OR one of its dependent packages (directly or indirectly) requires code to be synced. Uni-directional (e.g., private to public) syncing is straightforward. Bi-directional syncing (e.g, private to public and public to private) adds some cognitive overhead. I started to talk about “syncing” above. To expand a bit, given that we use git as our version control system, we will be syncing commits. This is the problem within the problem, e.g., how do you safely sync commits between two repositories? The rest of this post will explore the required steps for us to make this happen. Coming up with a convention for configuring and statically identifying open-source packages Identification of an open-source package’s dependent packages (direct and indirect) Syncing commits between repositories Automating the process Marking packages to be open-sourced Given that we use pnpm’s workspace concept, our monorepo’s packages are all node modules, independent of whether their src code is written in JavaScript. Said another way, every package in our monorepo has a , the dependencies of which define our workspace's topology. package.json The schema/type definition for a package.json file is , allowing us to add arbitrary fields to the top-level quite flexible JSON. To mark packages as open source we introduced an optional boolean field named . openSource export DoptPackageJson extends PackageJson {
  openSource?: boolean;
} You can see the usage of this field in our . JavaScript Block API client {
 "name": "@dopt/blocks-javascript-client",
  "version": "1.0.0",
  "private": false,
  "description": "A generated JavaScript API client for Dopt's blocks API",
  ...
  "openSource": true, // <= new field configuring this package as open source
} Having marked packages, we need a way to identify them programmatically. Whether using pnpm, yarn, or npm to configure workspaces, they all offer some tooling, albeit primitive, for listing packages in the workspace, etc. We ended up wrapping pnpm’s functionality in a package called , which is conveniently open-sourced from our private monorepo. The code to locate open-source packages in the monorepo looks something like this. @dopt/wutils import fs from 'node:fs';
import path from 'node:path';

import { getPackageLocationsSync } from '@dopt/wutils';

export const openSourcePackages = getPackageLocationsSync()
  .map((workspacePath) =>
    JSON.parse(
      fs.readFileSync(
        path.resolve(process.cwd(), `${workspacePath}/package.json`),
        { encoding: 'utf8' }
      )
    )
  )
  .filter((pkg) => pkg.openSource); Static analysis: filtering to open source packages and their dependents Now that we’ve marked open source packages as such and came up with a way of filtering down the monorepo to that set of packages, we should be able to script a solution for identifying a package's dependent packages (both direct and indirect). We have two options for tools that can help us with this part, pnpm or turborepo. We use pnpm as our package manager and turbo as our monorepo build tool. Since both solve monorepo-related problems, they both offer tools for filtering the monorepo and doing static analysis related to dependencies. See the links below. pnpm turbo Turbo's Filter API design is heavily inspired by pnpm’s. In this case, we ended up using pnpm, but either would have worked just fine. Attached below is an extension of the example above that illustrates how to use pnpm’s filtering syntax to select a package and its dependencies (direct and non-direct). ... import { execSync } from 'child_process';

// Use the function above to filter workspace packages to open source packages
const openSourcePackages = openSourcePackages();

// Use the open source packages to template pnpm filtering
const templatedPnpmFilter = `pnpm ls -r --depth -1 ${openSourcePackages
  .map(({ name }) => ` --filter ${name}... `)
  .join('')} --json`;

// Execute the templated pnpm command
const targetPackages = JSON.parse(execSync(templatedPnpmFilter).toString()); Git 🪄: filtering and syncing commits We have open-source packages and their dependent packages. The next step is to identify changes that impacted those packages. In git terms, “changes” are going to be git commits. So we are going to want to operate on the git commit history. Operations like this are aptly termed “history rewrites” and there are a few tools that are meant to help with this, given how complicated and dangerous it can become. git filter-branch git-filter-repo The former and suggests using the latter instead, which is exactly what we did. warns against its usage Our goal with this tool will be to extract the git history for each path associated with the open-source packages and their dependents. Building from the code example in the previous section, we can leverage the collection of (which contains the path to that package) to form the query. targetPackages git filter-repo import { getPackagesSync } from '@dopt/wutils';

type PackageDef = {
  name: string;
  path: string;
};

// Get all the packages in the monorepo
const packages: PackageDef[] = getPackagesSync();

// Filter all packages by target packages and form query
const templatedGitFilterRepoQuery = `git filter-repo ${packages
    .filter(({ name }) => targetPackages.includes(name))
    .map(({ path }) => `--path ${path}`)
    .join(' ')}`;

// Execute the query, rewriting your git history on the
// current branch to only the desired commits.
execSync(templatedGitFilterRepoQuery)).toString(); This all happened on a clean clone of our private monorepo and we now have a history that has been filtered down to what I’ll call open-source commits. How do we sync these commits over to our other repository? # Create a fresh clone of the private monorepo
git clone git@github.com:<org>/<private_monorepo>.git
cd $private_monorepo;

# Run the git commit filter script
node ./filter-to-open-source-commits.mjs

# Move up a directory so the repose are siblings
cd ..;

# Create a fresh clone of the open source monorepo
git clone git@github.com:<org>/<opensource_monorepo>.git
cd $opensource_monorepo;

git checkout -b sync-commits-from-private-monorepo;
git remote add source ../private_monorepo;
# Replace "main" with the branch name in the private monorepo
git pull source main --allow-unrelated-histories --strategy-option theirs --no-edit;

# Finally, set your remote and push!
git remote set-url --push  origin https://github.com/<org>/<opensource_monorepo>.git
git push --set-upstream origin sync-commits-from-private-monorepo; Automating this workflow With everything working manually, our next goal is to “set and forget” this workflow/pipeline. We solved this in , creating a GitHub action that is invoked on any merge to the main branch of our private monorepo. CI/CD Check it out the code for the GitHub Action below. Additionally, here’s a recent to one of the pull requests this action created in the open-source repository. link # Example CI/CD
name: Sync OSS Packages
on:
  merge: main
jobs:
    steps:
      - name: Check out the monorepo
        with:
          repository: dopt/monorepo
          path: ./monorepo

      - name: Check out the open monorepo
        with:
          repository: dopt/odopt
          path: ./odopt

      - name: Filter the open-source packages
        working-directory: monorepo/
        run: node ./filter.js;

      - name: Sync commits
        working-directory: odopt/
        run: |
          git checkout -b sync/${{ github.run_id }};
          git remote add source ../monorepo;
          git pull source main --allow-unrelated-histories --strategy-option theirs --no-edit;

      - name: Push commits
        working-directory: odopt/
        run: |
          git remote set-url --push  origin https://github.com/dopt/odopt.git
          git push --set-upstream origin sync/${{ github.run_id }}; Learnings First and foremost, we learned that you can have your cake and eat it too, i.e., enjoy all the benefits of a monorepo while still open-sourcing parts of it. It definitely requires a decent bit of setup and cognitive overhead to understand the problems you need to solve, but by following a similar pattern you can also share pieces of your monorepo with the community with little continued maintenance. We’ve not touched this pipeline since putting it in place! Lastly, our use case was primarily open-source API clients and SDKs, but having this pipeline has promoted a healthy habit of open-sourcing packages/modules that we think the community would benefit from e.g., please (GitHub, npm) mercator (GitHub, npm) wutils (GitHub) Check out to see what else we are building and sharing! odopt Also published here. The featured image for this piece was generated with Kadinsky v2 Prompt: Illustrate code locks.

Open-Sourcing Code from a Private Monorepo

255 Stories To Learn About Hacking

207 Stories To Learn About Golang

338 Stories To Learn About Github

Photo by on NGO TUNG Unsplash My company, CriticalBlue, provides a remote mobile app authentication service called . An Approov SDK is provided as a drop-in library to native iOS and Android app developers. Approov With many of our customers using or experimenting with React Native, I wanted to provide a convenient Javascript module which exposes the native Approov SDK functionality to React Native developers. Overall, creating my first React Native native module was surprisingly straightforward. All code for my initial proof of concept is available in a . github repository React Native Bridge For react Native, Facebook provides a solid which goes over the basics, including how to set up an application and how the underlying UI components differ from the usual React web elements. getting started guide (from ) React Made Native Easy Architecturally, there are two important threads running in each React Native application — one a main UI thread and the other running a Javascript VM. The two threads interact through a bridge whose communication is asynchronous, serialized, and batched, decoupling the two systems as much as possible. While the bulk of the React Native app is described in React and runs on the Javascript VM, the UI is rendered using the native platform’s UI elements, and actions which alter the app’s UI are passed as messages through the bridge from the VM to the app’s main UI thread. System functionality and libraries developed for the native device environment can be exposed to the Javascript VM using React Native’s native module interface and accessed through the React Native bridge. Approov Native SDK The Approov SDK is a drop-in native iOS or Android library. It interfaces with the cloud-based Approov authentication service which validates that the app is genuine, untampered, and not a bot. An app integrity token is returned from the authentication service, and that token is sent with each API call to ensure that the back-end API service is dealing with a known and genuine front-end request. The basic operation we will expose in our native module proof of concept is , an asynchronous operation in the native SDK. fetchApproovToken() (Approov-protected API call) Before each back-end API call requiring app authentication, the client app makes a fetch token request. If a fresh token is needed, the SDK makes a remote attestation request, and the attestation service cryptographically authenticates the app and responds with an app integrity token. The token has a short lifetime and is signed by a secret known only to the Approov service and the app’s back-end service. No secret is stored in the app, and in fact the app does not know whether the returned token is valid or not. The app simply adds the integrity token to the back-end API call, and the back-end server validates that the token has not expired and is properly signed before processing the request. Approov Demo Service Approov offers a which provides demonstration iOS and Android SDKs and a back-end service with two endpoints: downloadable demo , which provides a publicly accessible test point. https://demo-server.approovr.io/hello , which provides a random shape only if the request contains a valid integrity token. https://demo-server.approovr.io/shapes We’ll use the Android SDK with the back-end service to demonstrate a simple React Native app using Approov. A version of this example using the iOS SDK with React native is also available. Saying Hello I started my React Native project using create-react-native-app (CRNA). Follow the to setup your React Native environment and then: CRNA installation instructions $ create-react-native-app rndemo I will be adding native code to the app, so go ahead and eject now from create-react-native-app: $ yarn eject
... ? What should your Android Studio and Xcode projects be called? rndemo Generating the iOS folder.
Generating the Android folder.
... $ cd rndemo Ejecting is permanent! Please be careful with your selection. ? How would you like to eject from create-react-native-app? React Native: I’d like a regular React Native project. We have a couple of questions to ask you about how you’d like to name your app: ? What should your app appear as on a user’s home screen? RN Demo Wrote to app.json, please update it manually in the future. Select a regular React Native project and name it as you wish. The iOS and Android projects are generated, and you will need and/or build environments installed. Native code will be added to the native Android project later on. Xcode Android Studio We will experiment with a very simple proof of concept app that will use the demo server hello endpoint to validate our network connectivity. React Native implements the for networking. We combine the connection check, UI rendering, and styling all in the file: fetch API App.js } }) })
    }) })
    });
  } }; );
  }
} }, }, }, }, },
}); import React from 'react' ; import { View, Image, Text, Button, StyleSheet } from 'react-native' ; import ShapeView from './ShapeView' export default class App extends React . Component { constructor ( props ) { super (props); this .state = { shape : 'logo' , status : '' }; // check connection checkConnection = () => { fetch( 'https://demo-server.approovr.io/hello' , { method : 'GET' , .then( ( response ) => response.text()) .then( ( text ) => { this .setState( previousState => { return { shape : 'hello' , status : 'connected' }; .catch( ( error ) => { this .setState( previousState => { return { shape : 'confused' , status : 'not connected' }; // render the app screen render ( ) { let pic = { uri : 'https://approov.io/images/approov_largelogo.png' return ( < View style = {styles.container} > < View style = {styles.header} > < Text style = {{fontSize: 24 }}> Approov Shapes </ Text > </ View > < ShapeView style = {styles.content} shape = {this.state.shape} status = {this.state.status}/ > < View style = {styles.footer} > < View style = {styles.buttonBar} > < Button onPress = {this.checkConnection} title = "Test Hello" /> </ View > </ View > </ View > // flexbox styles const styles = StyleSheet.create({ container : { flex : 1 , flexDirection : 'column' , backgroundColor : '#fff' , margin : 10 , header : { flex : .1 , flexDirection : 'row' , justifyContent : 'center' , content : { flex : .8 , flexDirection : 'column' , justifyContent : 'center' , alignItems : 'center' , footer : { flex : .1 , flexDirection : 'row' , justifyContent : 'center' , buttonBar : { flex : 1 , flexDirection : 'row' , alignItems : 'flex-end' , justifyContent : 'space-around' , // end of file The top-level App component is registered in the file. index.js The main view is rendered by a stateless view component which displays a choice of image and a status message: }; );
} }
}); import React from "react" ; import { View, Image, Text, StyleSheet } from "react-native" ; const shapeView = ( props ) => { const imgSrc = { 'logo' : require ( './assets/approov_largelogo.png' ), 'hello' : require ( './assets/hello.png' ), 'confused' : require ( './assets/confused.png' ), 'Rectangle' : require ( './assets/rectangle.png' ), 'Square' : require ( './assets/square.png' ), 'Triangle' : require ( './assets/triangle.png' ), 'Circle' : require ( './assets/circle.png' ) return ( < View style = {props.style} > < Image source = {imgSrc[props.shape]} style = {styles.shapeImg} /> < Text style = {{fontSize: 24 , marginTop: 10 }}> {props.status} </ Text > </ View > const styles = StyleSheet.create({ shapeImg : { resizeMode : 'contain' , height : 256 , width : 256 export default shapeView; // end of file I am using Android for these examples, but this works similarly on iOS. Fire up an Android emulator (you may need to launch Android Studio for this) or connect a phone via . In the directory, launch the app: adb rndemo $ yarn run android $ cd rndemo You should see a screen like this: Push the button and you should see a connected message if everything went okay: TEST HELLO This validates network communication between our React Native app and the demo server. You can set airplane mode on your phone or emulator and push the test button again to verify there is then no longer a connection. The Approov Native Module The Approov demo package includes a README, the iOS and Android Approov demo libraries, sample clients, and app registration tools. Download the , and save the app registration token which is included in your download email. demo package The Approov SDK includes the native code we want to expose to React Native. It must be included in the iOS or Android native projects which were generated when we ejected the create-react-native-app. For Android, this project is located at rndemo/android. Import the Approov SDK into the Android project by following these from the . instructions Approov docs An Android native module is described in Java by extending the ReactContextBaseJavaModule class. The getName() method must be implemented and provides the name of the module to Javascript. Methods exposed to React Native are adorned with @ReactMethod and may provide Javascript callback or promise mechanisms. We’ll use promises in our example. Facebook’s describes other capabilities such as sending events to Javascript and listening to lifecycle events. native module page We initialize the default configuration for Approov authentication in the native module constructor, and define ‘Approov’ in the getName() call. The exposed call wraps the asynchronous native and settles a promise when the token fetch completes. fetchApproovToken() fetchApproovToken() private Context context; ApproovConfig config = ApproovConfig.getDefaultConfig(reactContext);
            ApproovAttestation.initialize(config); }
    }

    @Override }

    @ReactMethod @Override promise.resolve(results.getToken()); }
        }, url);
    }
} package com.criticalblue.approov; import ... import com.criticalblue.attestationlibrary.ApproovAttestation; import com.criticalblue.attestationlibrary.ApproovConfig; import com.criticalblue.attestationlibrary.TokenInterface; class ApproovModule extends ReactContextBaseJavaModule { private static final String E_APPROOV_ERROR = "E_APPROOV_ERROR" ; public ApproovModule ( ReactApplicationContext reactContext ) { super (reactContext); this .context = reactContext; try { } catch (IllegalArgumentException ex) { } catch (MalformedURLException ex) { public String getName ( ) { return "Approov" ; public void fetchApproovToken ( final String url, final Promise promise ) { ApproovAttestation.shared().fetchApproovToken( new TokenInterface ( ) { public void approovTokenFetchResult ( ApproovResults results ) { if (results.getResult() == ApproovAttestation.AttestationResult.SUCCESS) else promise.reject(E_APPROOV_ERROR, "Failed to fetch Approov Token" ); A bundles and creates one or more native modules: ReactPackage @Override }

    @Override }
} package com.criticalblue.approov; import ... public class ApproovPackage implements ReactPackage { public List<ViewManager> createViewManagers ( ReactApplicationContext reactContext ) { return Collections.emptyList(); public List<NativeModule> createNativeModules ( ReactApplicationContext reactContext ) { List<NativeModule> modules = new ArrayList<>(); modules.add( new ApproovModule(reactContext)); return modules; The project’s main application implements ReactApplication and creates and returns a list of module packages. We add the Approov package to the list in . getPackages() @Override }

    @Override );
    }

    @Override }
  };

  @Override }

  @Override }
} package com.rndemo; import ... import com.criticalblue.approov.ApproovPackage; public class MainApplication extends Application implements ReactApplication { private final ReactNativeHost mReactNativeHost = new ReactNativeHost ( this ) { public boolean getUseDeveloperSupport ( ) { return BuildConfig.DEBUG; protected List<ReactPackage> getPackages ( ) { return Arrays.<ReactPackage>asList( new MainReactPackage(), new ApproovPackage() protected String getJSMainModuleName ( ) { return "index" ; public ReactNativeHost getReactNativeHost ( ) { return mReactNativeHost; public void onCreate ( ) { super .onCreate(); SoLoader.init( this , /* native exopackage */ false ); On the Javascript side, the Approov native module will now be included in the imported from . In our implementation, returns a normal javascript promise: NativeModules react-native Approov.fetchApproovToken() NativeModules.Approov.fetchApproovToken(input) }) }); import {NativeModules} from 'react-native' ; .then( token => { // do something useful... .catch( ( error ) => { throw error; Bridging the native and Javascript environments was surprisingly straightforward. Interceptors Many networking libraries, such as and tp, include the concept of an interceptor. Interceptors can be used to intercept network requests and responses and inject some additional processing. Axios OkHt When implementing natively with the Android SDK, most customers use interceptors to fetch an Approov token and add it to each API request’s headers, so we’ll want to fully implement this abstraction in our production module. For this simple example though, we’ll hardwire the interception in a fetchWithToken() call. In the fetchWithToken() method, when the native fetch token call completes, if the promise is resolved, we add the token to the input request headers and make a fetch() call with the augmented input request. When completed, the fetch returns a resolved promise holding the API server’s response. } }
                }) })
        }) })
}; import {NativeModules} from 'react-native' ; const fetchWithToken = ( input, options ) => { return NativeModules.Approov.fetchApproovToken(input) .then( token => { let optionsA = (options? {...options, headers :{ ...options.headers}}:{ headers : {}}); optionsA.headers[ 'Approov-Token' ] = token; return fetch(input, optionsA) .then( ( response ) => { if (response.ok) { return response; else { throw new Error ( 'HTTP response status is ' + response.status); .catch( ( error ) => { throw error; .catch( ( error ) => { throw error; const Approov = Object .assign({ fetch : fetchWithToken }, NativeModules.Approov); export default Approov; For convenience, we create an Approov object from the NativeModules.Approov object, adding a fetch() method which is actually the fetchWithToken() method, and then we export this as the Approov module. Getting Shapes Now we are ready to use the Approov object for authentication. We add a getShape() method inside our App which makes an Approov.fetch(request) call to authenticate and request a random shape value. Once the fetch completes, the App component state updates, triggering a render() call which causes the ShapeView to display an updated shape and status message. A GET SHAPES button is added to the button bar to request new shapes. }) } }) })
    }) })
    });
  } }; );
  }
} import Approov from './Approov' ; class App extends React . Component { // unchanged code ommitted for brevity... // get shape getShape = () => { Approov.fetch( 'https://demo-server.approovr.io/shapes' , { method : 'GET' , .then( ( response ) => { if (!response.ok) { throw new Error ( 'HTTP response status not OK.' ); return response.text(); .then( ( text ) => { this .setState( previousState => { return { shape : text, status : '' }; .catch( ( error ) => { const message = '' + error.message; this .setState( previousState => { return { shape : 'confused' , status : message }; // render the app screen render ( ) { let pic = { uri : 'https://approov.io/images/approov_largelogo.png' return ( < View style = {styles.container} > < View style = {styles.header} > < Text style = {{fontSize: 24 }}> Approov Shapes </ Text > </ View > < ShapeView style = {styles.content} shape = {this.state.shape} status = {this.state.status}/ > < View style = {styles.footer} > < View style = {styles.buttonBar} > < Button onPress = {this.checkConnection} title = "Test Hello" /> < Button onPress = {this.getShape} title = "Get Shape" /> </ View > </ View > </ View > Everything looks good, but when we request a new shape, we see a failure with a 400 status code, suggesting there is a problem with the client request. Failure to fetch a shape The call fails because the integrity token added by Approov is invalid. Until our example app is properly registered with the Approov service, the fetchWithToken() call will always fail the authentication check. Command line registration tools are included in the demo download. To register the app, issue a registration request specifying the App’s APK bundle and the app registration token you saved from the demo download email. As a courtesy to other demo users, set your registration to expire after a few hours using the -e flag: $ ./registration -t <registration-token>
   -e 2h
Submitting data… $ cd <<approov-demo-package>> /registration-tools/ Android/Mac/ -a <<rndemo-project>> /android/ app/build/outputs/apk/app-debug.apk Success : new app signature added to database.always be done. Once the app is registered and can be properly authenticated, pressing the GET SHAPES button should return one of these shapes: (Successfully fetching random shapes) Man in the Middle Attacks The security of the communication channel is very important during API calls. If the channel is insecure, an API call could be intercepted and modified. An integrity token, although it has a short lifetime, could be observed in the insecure channel and used to make malicious API calls with impunity. Despite using HTTPS/TLS when making API requests, an attacker who controls both the network and the mobile device can easily setup a to steal and quickly reuse Approov tokens before they expire. Man in the Middle (MitM) attack To counter MitM attacks, mobile clients should use which checks that the certificate or public key presented by the back-end service is known specifically by the client app. Other certificates, though they might appear authentic, will be rejected by the client, and no API calls will be made. certificate or public key ‘pinning’ Implementing pinning in React Native is a bit complicated and will be described in a separate article and integrated into this example’s code repository. Going Further We’ve demonstrated a native module implementation in React Native with a hardwired interceptor successfully providing app authentication and API protection. A production quality native module implementation for React Native would generalize the interceptor functionality, add convenience configuration methods, and provide full MitM protection. For comparison, a similar already exists for and hybrid apps. Approov plugin library Cordova Ionic All code for this example is located on . github Thanks for reading! For more information on mobile API security, check out . www.approov.io I’d really appreciate it if you recommend this post (by clicking the 👏 button) so other people can find it.

First experiences with React Native: bridging an Android native module for app authentication

The Wheels of Chance by H. G. Wells, is part of the HackerNoon Books Series. You can jump to any chapter in this book here . HOW MR. HOOPDRIVER REACHED MIDHURST HOW MR. HOOPDRIVER REACHED MIDHURST It was one of my uncle's profoundest remarks that human beings are the only unreasonable creatures. This observation was so far justified by Mr. Hoopdriver that, after spending the morning tortuously avoiding the other man in brown and the Young Lady in Grey, he spent a considerable part of the afternoon in thinking about the Young Lady in Grey, and contemplating in an optimistic spirit the possibilities of seeing her again. Memory and imagination played round her, so that his course was largely determined by the windings of the road he traversed. Of one general proposition he was absolutely convinced. “There's something Juicy wrong with 'em,” said he—once even aloud. But what it was he could not imagine. He recapitulated the facts. “Miss Beaumont—brother and sister—and the stoppage to quarrel and weep—” it was perplexing material for a young man of small experience. There was no exertion he hated so much as inference, and after a time he gave up any attempt to get at the realities of the case, and let his imagination go free. Should he ever see her again? Suppose he did—with that other chap not about. The vision he found pleasantest was an encounter with her, an unexpected encounter at the annual Dancing Class 'Do' at the Putney Assembly Rooms. Somehow they would drift together, and he would dance with her again and again. It was a pleasant vision, for you must understand that Mr. Hoopdriver danced uncommonly well. Or again, in the shop, a sudden radiance in the doorway, and she is bowed towards the Manchester counter. And then to lean over that counter and murmur, seemingly apropos of the goods under discussion, “I have not forgotten that morning on the Portsmouth road,” and lower, “I never shall forget.” At Northchapel Mr. Hoopdriver consulted his map and took counsel and weighed his course of action. Petworth seemed a possible resting-place, or Pullborough; Midhurst seemed too near, and any place over the Downs beyond, too far, and so he meandered towards Petworth, posing himself perpetually and loitering, gathering wild flowers and wondering why they had no names—for he had never heard of any—dropping them furtively at the sight of a stranger, and generally 'mucking about.' There were purple vetches in the hedges, meadowsweet, honeysuckle, belated brambles—but the dog-roses had already gone; there were green and red blackberries, stellarias, and dandelions, and in another place white dead nettles, traveller's-joy, clinging bedstraw, grasses flowering, white campions, and ragged robins. One cornfield was glorious with poppies, bright scarlet and purple white, and the blue corn-flowers were beginning. In the lanes the trees met overhead, and the wisps of hay still hung to the straggling hedges. Iri one of the main roads he steered a perilous passage through a dozen surly dun oxen. Here and there were little cottages, and picturesque beer-houses with the vivid brewers' boards of blue and scarlet, and once a broad green and a church, and an expanse of some hundred houses or so. Then he came to a pebbly rivulet that emerged between clumps of sedge loosestrife and forget-me-nots under an arch of trees, and rippled across the road, and there he dismounted, longing to take off shoes and stockings—those stylish chequered stockings were now all dimmed with dust—and paddle his lean legs in the chuckling cheerful water. But instead he sat in a manly attitude, smoking a cigarette, for fear lest the Young Lady in Grey should come glittering round the corner. For the flavour of the Young Lady in Grey was present through it all, mixing with the flowers and all the delight of it, a touch that made this second day quite different from the first, an undertone of expectation, anxiety, and something like regret that would not be ignored. It was only late in the long evening that, quite abruptly, he began to repent, vividly and decidedly, having fled these two people. He was getting hungry, and that has a curious effect upon the emotional colouring of our minds. The man was a sinister brute, Hoopdriver saw in a flash of inspiration, and the girl—she was in some serious trouble. And he who might have helped her had taken his first impulse as decisive—and bolted. This new view of it depressed him dreadfully. What might not be happening to her now? He thought again of her tears. Surely it was merely his duty, seeing the trouble afoot, to keep his eye upon it. He began riding fast to get quit of such selfreproaches. He found himself in a tortuous tangle of roads, and as the dusk was coming on, emerged, not at Petworth but at Easebourne, a mile from Midhurst. “I'm getting hungry,” said Mr. Hoopdriver, inquiring of a gamekeeper in Easebourne village. “Midhurst a mile, and Petworth five!—Thenks, I'll take Midhurst.” He came into Midhurst by the bridge at the watermill, and up the North Street, and a little shop flourishing cheerfully, the cheerful sign of a teapot, and exhibiting a brilliant array of tobaccos, sweets, and children's toys in the window, struck his fancy. A neat, bright-eyed little old lady made him welcome, and he was presently supping sumptuously on sausages and tea, with a visitors' book full of the most humorous and flattering remarks about the little old lady, in verse and prose, propped up against his teapot as he ate. Regular good some of the jokes were, and rhymes that read well—even with your mouth full of sausage. Mr. Hoopdriver formed a vague idea of drawing “something”—for his judgment on the little old lady was already formed. He pictured the little old lady discovering it afterwards—“My gracious! One of them Punch men,” she would say. The room had a curtained recess and a chest of drawers, for presently it was to be his bedroom, and the day part of it was decorated with framed Oddfellows' certificates and giltbacked books and portraits, and kettle-holders, and all kinds of beautiful things made out of wool; very comfortable it was indeed. The window was lead framed and diamond paned, and through it one saw the corner of the vicarage and a pleasant hill crest, in dusky silhouette against the twilight sky. And after the sausages had ceased to be, he lit a Red Herring cigarette and went swaggering out into the twilight street. All shadowy blue between its dark brick houses, was the street, with a bright yellow window here and there and splashes of green and red where the chemist's illumination fell across the road. About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books. This book is part of the public domain. H. G. Wells (2009). The Wheels of Chance. Urbana, Illinois: Project Gutenberg. Retrieved October 2022, from https://www.gutenberg.org/files/1264/1264-h/1264-h.htm This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at www.gutenberg.org, located at https://www.gutenberg.org/policy/license.html.

HOW MR. HOOPDRIVER REACHED MIDHURST

AdTech Holding is committed to high technologies that ensure top-notch quality for all its products. Our business approach relies much on software development and thus implies having a team of strong IT specialists who have not only enormous expertise but also an inspiration to grow and create. We always encourage our tech teams to go beyond their normal daily, quarterly, and annual tasks — and it turns into brand new ideas and insights. Today, we are glad to share one of the great examples of such an insight. Our AppLab team is responsible for developing mobile apps, but recently they have gone beyond the limits and created their own app store platform. We spoke to Artem Kovardin, the Head of Product Development of App Lab, to get the idea of why you might need your app store platform and a detailed guide on how to build it. Reasons for building your own app store The first question that might arise is why would anyone need a store when there are already Google Play and AppStore. However, Artem shared two potential situations when such a solution can be very reasonable — and these cases include both personal and business purposes. Reason 1: Building a corporate infrastructure Many companies have their operations based on particular apps. Keeping them in the in-house store might significantly simplify access and control over the whole infrastructure. Besides, you can disable downloads of local apps from the other stores for all employers’ devices. Reason 2: Helping senior family members We mentioned personal reasons, and here is one. Seniors often face issues getting around the modern app stores and struggle to find and install the apps they need. Your own store will solve this problem: you can create a very simplified interface and control what your loved ones install on their devices. Creating App Store Platform: Ready Guide So you are determined to implement such a solution in your company or need to build a store for other reasons. Artem shared the best practices from his team’s experience and we are ready to bring out a step-by-step guide including all necessary tools. Step 1. Planning Like with every project, it’s essential to determine the final goal of the whole work. In our case, it is basically an app that will help to install other apps. The next question is how this app will work. Here are the tools that we recommend using according to our experience: Interface Flutter Native Logic Kotlin APK files downloading Company’s own API API The Go Language Another important point is how we are going to add the apps to the store. The work of a store platform implies that we require apps in the form of APK files. Some of them have direct links, published by developers. However, most apps are only available via Google Play, which means that the project requires a Google Play parser. To sum up, the whole ecosystem of the future app store platform will consist of three parts: Step 2. App Development Flutter allows the creation of an application store with minimum time and effort. Thus, we will mention the most complicated points that might cause difficulties. To manage state in the app, our team used two packages: along with . Such a solution turned out to be the simplest and the most convenient option for a Flutter app state management. provider state_notifier Another important take: before a user can install an app from the storage, they will need to download it first — and this step requires testing. To test how it works, the team added the APK file to a server to make the file available for download. Now you need to download it in the application: void download(String url, {Function? success, Function? error}) async {
	var name = basename(url);
	var request = http.Request('GET', Uri.parse(url));
	var response = client.send(request);
	String dir = (await getApplicationDocumentsDirectory()).path;

	List<List<int>> chunks = [];
	int downloaded = 0;

	response.asStream().listen((http.StreamedResponse r) {
    	r.stream.listen((List<int> chunk) {
            	print('downloaded: ${downloaded * Megabyte}');

            	chunks.add(chunk);
            	downloaded += chunk.length;
        	}, onDone: () async {
  	          print('downloaded: ${downloaded * Megabyte}');

            	var path = '$dir/$name';

            	File file = new File(path);
            	final Uint8List bytes = Uint8List(downloaded);
            	int offset = 0;
            	for (List<int> chunk in chunks) {
                    bytes.setRange(offset, offset + chunk.length, chunk);
                	offset += chunk.length;
            	}

            	await file.writeAsBytes(bytes);

            	if (success != null) {
                	success(path);
            	}

            	return;
        	}, onError: (err) async {
            	if (error != null) {
                	error();
            	}
    	});
	});
} The `getApplicationDocumentsDirectory()` function returns the path to the directory where you need to download the APK file. With the help of the `basename(url)` function we get the file name; to start background loading, we use the `response.asStream()`, and when the downloading is finished, we use the callback `success(path);`. As a result, we have the file and can install it. Here we require a part of a native Kotlin code. To get this code, we need to install the__ __ package and create particular contracts in the pideons/install/apk.dart file. pigeon import 'package:pigeon/pigeon.dart';


class InstallRequest {
  String? file;
}

class InstallResponse {
  bool? status;
}

@HostApi()
abstract class InstallApk {
  @async
  InstallResponse install(InstallRequest request);
} Then, we generate interfaces for a native code and the Dart code: flutter pub run pigeon \
  --input pigeons/install/apk.dart \
  --dart_out lib/pigeons/install/apk.dart \
  --java_out ./android/app/src/main/java/ru/kovardin/getapp/pigeons/install/Apk.java \
  --java_package "ru.kovardin.getapp.pigeons.install" Pigeon generates Java files, but we can use them in the Kotlin native code. Now it’s important to support `InstallApk` interfaces from the generated Java code: package ru.kovardin.getapp.install

import android.app.Activity
import android.content.Intent
import android.content.pm.PackageManager
import android.content.pm.ResolveInfo
import android.net.Uri
import android.os.Build
import android.util.Log
import androidx.core.content.FileProvider
import ru.kovardin.getapp.pigeons.install.Apk
import java.io.File


open class Apk(val context: Activity): Apk.InstallApk {
	override fun install(request: Apk.InstallRequest, result: Apk.Result<Apk.InstallResponse>?) {
    	Log.d("APK", "install apk ${request.file}")

    	try {
        	val file = File(request.file ?: "")
        	val intent = Intent(Intent.ACTION_VIEW)
        	val authority =  context.getApplicationContext().getPackageName().toString() + ".provider"
        	val type = "application/vnd.android.package-archive"

        	if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {
            	val apk: Uri = FileProvider.getUriForFile(
                    	context,
  	                  authority,
                    	file
            	)

                intent.setDataAndType(apk, type)
            	val infos: List<ResolveInfo> = context.getPackageManager().queryIntentActivities(intent, PackageManager.MATCH_DEFAULT_ONLY)
            	for (info in infos) {
                    context.grantUriPermission(authority, apk, Intent.FLAG_GRANT_WRITE_URI_PERMISSION or Intent.FLAG_GRANT_READ_URI_PERMISSION)
            	}
                intent.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP or Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_GRANT_WRITE_URI_PERMISSION or Intent.FLAG_GRANT_READ_URI_PERMISSION)
                intent.putExtra(Intent.EXTRA_NOT_UNKNOWN_SOURCE, true)

        	} else {
            	intent.setAction(Intent.ACTION_VIEW)
                intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_ACTIVITY_NEW_TASK)
                intent.putExtra(Intent.EXTRA_NOT_UNKNOWN_SOURCE, true)
                intent.setDataAndType(Uri.fromFile(file), type)
        	}
            context.startActivity(intent)
    	} catch (e: Exception) {
        	e.printStackTrace()
    	}

    	val response = Apk.InstallResponse();
    	response.status = true;
    	result?.success(response)
	}
} Overall, the app installation is the launch of intent with the right type and the APK file in parameters. The rest of the work is done by Android — automatically. The next thing we recommend to do is to check the SDK version. The future logic we will use to work with the APK file will depend on this SDK version. For SDK 23 or earlier versions, we can use a standard access to a file: `Uri.fromFile(file)`. This code is executed in the else section: intent.setAction(Intent.ACTION_VIEW)
intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_ACTIVITY_NEW_TASK)
intent.putExtra(Intent.EXTRA_NOT_UNKNOWN_SOURCE, true)
intent.setDataAndType(Uri.fromFile(file), type) Things get more complicated when you work with SDK 24 or later versions. To do things correctly, we will need to add a separate section to the AndroidManifest.xml file: <application
    	android:allowBackup="true"
        android:label="@string/app_name">
    	<provider
            android:name="android.support.v4.content.FileProvider"
        	android:authorities="${applicationId}.authorityStr"
            android:exported="false"
            android:grantUriPermissions="true">
        	<meta-data
                android:name="android.support.FILE_PROVIDER_PATHS"
                android:resource="@xml/paths"/>
    	</provider>
</application> The`@xml/paths` is a separate resource file: paths.xml from the xml folder. We need to define this file’s content: <?xml version="1.0" encoding="utf-8"?>
<paths xmlns:android="http://schemas.android.com/apk/res/android">
	<external-path
            name="files_root"
            path="Android/data/${applicationId}" />
	<external-path
            name="external_files"
        	path="." />
	<root-path name="root" path="/data/" />
</paths> You will find a detailed guide on working with files in the Android SDK 24+ in developer documentation. Now we can call the native code from the Dart code. Pigeon generated the class that will be  used in the service. InstallApk final apk = InstallApk();
final response = await apk.install(InstallRequest(
	file: apk,
)); Another essential point is that you need to request a user permission before installing an APK. You can easily do it with the package. permission_handler Permission.storage.request().then((value) {
	print(value);

    Permission.requestInstallPackages.request().then((value) {
    	print(value);
	});
}); Step 3: API The easiest way to create API is to stick to the Go language, which perfectly suits these needs. To work with HTTP, our team recommends to use : a very simple, but efficient router. chi func (a *Api) Route(r chi.Router) {
  	r.Route("/v1", func(r chi.Router) {

        	r.Route("/apps", func(r chi.Router) {
              	r.Route("/{bundle}", func(r chi.Router) {
                    	r.Get("/", a.apps.One)
                    	r.Get("/download", a.apps.Download)
              	})
              	r.Get("/search", a.apps.Search)
              	r.Post("/updates", a.apps.Updates)
        	})

    	r.Get("/file/*", a.static.File)

        	// ...

  	})
} All APK files are stored in the AWS. To share them correctly, a service needs a handler, that will proxy all requests to files and add a special header: `headers.Set ("Content-Type", "application/vnd.android.package-archive"). This header is required to download files exactly in the .apk format: if you don’t use it, some Android devices will download them as .zip archives. func (h Static) File(w http.ResponseWriter, r *http.Request) {
  	headers := http.Header{}

  	ext := path.Ext(r.URL.Path)
  	if ext == ".apk" {
        	headers.Set("Content-Type", "application/vnd.android.package-archive")
  	}

  	proxy := httputil.ReverseProxy{
        	Director:  func(r *http.Request) {},
        	Transport: responseHeadersTransport(headers),
  	}

  	target := h.config.Scheme + path.Join(h.config.Cloud, strings.Replace(r.URL.Path, "file/", "", 1))
  	req, _ := http.NewRequest("GET", target, nil)
  	proxy.ServeHTTP(w, req)
} The rest of the work with API is standard, so we won’t call special attention to the further actions. To create an application store, you obviously need applications. They are all available in a ready store, and the easiest way is to get them from there. We are speaking about the Google Play that we need to parse — for information purposes only, of course. Part 4: Parser GitHub has a ready library for downloading APK files: . googleplay To start downloading files, you need to log in to Google Play: googleplay -email EMAIL -password PASSWORD This command will generate a special token file that we will use for requests. Then we generate a file with a device identifier — all requests will be performed from it: googleplay -device After everything is done, you will get access to information about an app you want to download: > googleplay -a com.google.android.youtube
Title: YouTube
Creator: Google LLC
UploadDate: 2022-05-12
VersionString: 17.19.34
VersionCode: 1529337280
NumDownloads: 11.822 B
Size: 46.727 MB
File: APK APK APK APK
Offer: 0 USD And download a particular version of any application: googleplay -a com.google.android.youtube -v 1529337280 The Result The AppLab team got the following platform as a result of all these efforts: It looks and works like a normal application store. And, after all, it turned out to be comparatively easy to develop. Artem insists that most part of the work lies on Android itself, while a developer needs to correctly download the APK files, get all permissions from a user, and launch a standard installation for Android. The result you see in the pictures shows an application store with a limited set of functions. All that it allows you to do is install apps on Android devices — not bad already, though. However, you can go further and add more things: Push Notifications via package, or package to realize the updates logic. firebase_messaging installed_apps

Stories, News & Mentions about GIFTPACK

Giftpack’s Stories on HackerNoon