Forem: Helio

Discover Your Notion Page Insights with Notion Statistics

Helio — Sat, 01 Jun 2024 11:12:41 +0000

In today's fast-paced digital world, staying organized and keeping track of your productivity is essential. Notion, a powerful tool for note-taking and project management, has become the go-to solution for many. But how do you measure the effectiveness of your Notion pages? Enter Notion Statistics, a game-changing platform designed to provide detailed insights into your Notion workspace.

Why Notion Statistics?

Notion Statistics offers a comprehensive summary of your Notion pages and databases, whether you prefer daily, weekly, or all-time overviews. Here’s why you should consider integrating it into your workflow:

Detailed Analytics: Understand how your Notion page evolves over time. With metrics like the total number of blocks and words, you get a clear picture of your content's volume and growth.
User-Specific Data: Notion Statistics not only tracks the overall changes but also provides insights into individual contributions. See how much you’ve written and how many blocks you’ve added, making it perfect for team environments where tracking individual input is crucial.
Time-Stamped Updates: Keep track of your progress with time-stamped data, helping you understand when the most significant changes occur. This feature is invaluable for identifying productivity trends and optimizing your workflow.

Key Features

Total Blocks and Words: Instantly see the total number of blocks and words in your Notion page. For instance, your page might have 217 blocks and 17,902 words as shown in the example, giving you a concrete idea of your content's scope.
Individual Contributions: Track your own activity. If you've added 2 blocks and 38 words recently, this information is clearly displayed, offering a personalized view of your contributions.
Regular Summaries: Choose between daily, weekly, or comprehensive summaries to suit your needs. This flexibility ensures you always have the most relevant data at your fingertips.

Upcoming Features

Notion Statistics is continuously evolving, with more features on the horizon. Stay tuned for updates that will further enhance your ability to track and analyze your Notion pages.

Get Started Today

Ready to take your Notion experience to the next level? Visit Notion Statistics and start exploring the full potential of your Notion workspace. With its user-friendly interface and powerful analytics, Notion Statistics is the perfect companion for anyone looking to optimize their productivity and stay on top of their Notion game.

Count everything in your Notion workspace

Helio — Wed, 29 May 2024 05:58:02 +0000

Hey everyone, I made a Notion counter for you, and it's still in progress, will coming soon.

When you add my Notion Integration to you notion workspace, and give me a root block id, our program will be able to crawl the whole blocks include the sub-pages and sub-databases, and store the count of blocks and words in our supabase backend.

Hope you like it.

Github: Notion Statistics
Demo

I Wrote a Knowledge Graph Render by LangChain

Helio — Tue, 30 Apr 2024 02:53:14 +0000

Hello and good morning.

I am a student from Chain. Recently, our teacher let us to write a KnowledgeGraph(as KG) render and save the graph to a graph database like neo4j.

Yeah, I know LangChain already provide the function to generate the graph data, but I still want to build my own version of KG. I tried many models like phi-3-mini, llama3-8b, but none of them work very well, so I changed my mind to use GLM-4 powered by ZhiPuAI, and it works very well. Here is the showcase: A very large image.

Although the showcase shows that KG render works very well, but I have some problem to fix:

I save graph to neo4j, but for the same label nodes, they are all connected to a same label nodes, although they have different type. Just like the word Key, Key could be related to many different fields like keyboard or database.
If I enable the update in args, render image will slow down the speed entirely, If there is a better way to show real time graph?

Type-Driven design in Rust

Helio — Fri, 12 Apr 2024 16:04:41 +0000

Hi. Good night. This is Helio, a Chinese student, who are learning Rust lang now. Today we gonna talk about type-driven design in Rust. This course is spring by "Type-Driven API Design in Rust" by Will Crichton, you can goto youtube to seek more details about type-driven design.

Let's look at a piece of python code now:

This code will generate a progress bar like this:

So what will happen when we using a unbounded list like:

The output will be like below one:

We find that if tqdm receive a bounded array, the progress bar will display, and the normal things like item/s also shown in the screen, but when tqdm receive a unbounded array like count(), it will only print the normal things like item/s, so let we design a rust lib called Progress. We will start at cargo new progress.

Start here

After enter cargo new progress, we create the project, and we run:

Nice. The first step we should think how to create a progress bar like tqdm, so we write down the following code:

We noticed that the output is ugly, generally we will improve this, we add static CLEAR: &str = "\x1B[2J\x1B[1;1H"; at the top of the code, and output will be more fine:

But once we need a progress bar, we also need to write this piece of code again and again, so we decided to design it to a function:

This output exactly equal to previous one. But if we don't use the Vec<i32>, instead, we use u32, what will happend? wrong! So we normally make the Vec<i32> a Vec<T>. But if we look one more ahead, we will use the Iterator instead of Vec<T>, so the code becomes:

Also the output will be equal to previous one. So if we want to go deep with the code, we should impl this one:



for n in Progress::new(v.iter()) {
    expensive_cal()
}

All right, let we create a struct named Progress, and define it like below one:

Ok, what if we design Progress use like this?



for n in v.iter().progress() {
    expensive_cal()
}

We need to impl something interesting:



trait ProgressIteratorExt<Iter> {
    fn progress(self) -> Progress<Iter>;
}

impl<Iter> ProgressIteratorExt<Iter> for Iter {
    fn progress(self) -> Progress<Iter> {
        Progress { iter: self, i: 1 }
    }
}

But something went wrong, because we impl progress for every type of T, i32/u32/... Code like below one will occur errors:



let a = 10;
let p = a.progress();
for _ in p { } // Here

`{integer}` is not an iterator
the trait `Iterator` is not implemented for `{integer}`, which is required by `Progress<{integer}>: IntoIterator`

The right version is like this:



trait ProgressIteratorExt<Iter> {
    fn progress(self) -> Progress<Iter>;
}

impl<Iter> ProgressIteratorExt<Iter> for Iter
where
    Iter: Iterator,
{
    fn progress(self) -> Progress<Iter> {
        Progress { iter: self, i: 1 }
    }
}

The output *** is too simple, we will add delims ('[', ']') to the code, so we update our struct:



struct Progress<Iter> {
    iter: Iter,
    i: usize,
    delims: (char, char),
    bound: Option<usize>,
}

The entire code will be like this:



#[allow(unused_variables)]
use std::{thread::sleep, time::Duration};

static CLEAR: &str = "\x1B[2J\x1B[1;1H";

struct Progress<Iter> {
    iter: Iter,
    i: usize,
    delims: (char, char),
    bound: Option<usize>,
}

impl<Iter> Progress<Iter>
where
    Iter: Iterator,
{
    pub fn new(iter: Iter) -> Self {
        Progress {
            iter,
            i: 1,
            delims: ('[', ']'),
            bound: None,
        }
    }
}

impl<Iter> Iterator for Progress<Iter>
where
    Iter: Iterator,
{
    type Item = Iter::Item;
    fn next(&mut self) -> Option<Self::Item> {
        if let Some(next) = self.iter.next() {
            match self.bound {
                Some(bound) => println!(
                    "{}{}{}{}{}",
                    CLEAR,
                    self.delims.0,
                    "*".repeat(self.i),
                    " ".repeat(bound - self.i),
                    self.delims.1
                ),
                None => println!("{}{}", CLEAR, "*".repeat(self.i),),
            }
            self.i += 1;
            return Some(next);
        } else {
            return None;
        }
    }
}

trait ProgressIteratorExt<Iter> {
    fn progress(self) -> Progress<Iter>;
}

impl<Iter> ProgressIteratorExt<Iter> for Iter
where
    Iter: Iterator,
{
    fn progress(self) -> Progress<Iter> {
        Progress {
            iter: self,
            i: 1,
            delims: ('[', ']'),
            bound: None,
        }
    }
}

impl<Iter> Progress<Iter>
where
    Iter: ExactSizeIterator,
{
    pub fn with_bound(mut self) -> Progress<Iter> {
        self.bound = Some(self.iter.len());
        Progress {
            iter: self.iter,
            i: 1,
            delims: self.delims,
            bound: self.bound,
        }
    }
}

fn expensive_cal(_n: &i32) {
    sleep(Duration::from_secs(1));
}

fn main() {
    let v = vec![1, 2, 3];
    for n in v.iter().progress().with_bound() {
        expensive_cal(n)
    }
}

Ok, the output is [***], the same as we think. We can also make a function called with_delims:



impl<Iter> Progress<Iter>
where
    Iter: ExactSizeIterator,
{
    pub fn with_delims(mut self, delims: (char, char)) -> Progress<Iter> {
        self.delims = delims;
        Progress {
            iter: self.iter,
            i: 1,
            delims: self.delims,
            bound: self.bound,
        }
    }
}

The output will becomes (***), right? What if we apply with_delims to unbounded array if the trait ExactSizeIterator not exist? Nothing will happen, even if the user config the delims. Ok.



for _ in (0..).progress().with_delims(('(', ')')) {
    expensive_cal()
}

The last concept I want to show you is Type-State, we write the code like this one:

The display will be impl like this one:

The rest part:

Finally we impl the Type-State version of Progress.

What exactly is the best way to keep your API secure

Helio — Mon, 08 Apr 2024 12:18:45 +0000

In this article, we will discuss several possible ways to protect the API from abuse. As the old saying goes, there is no such thing as a completely secure system in the world. We can't guarantee that the API won't be cracked, but we can artificially make it harder.

Let's say we have an POST request to /pay, and the body like:

{
  "amount": 100
}

We usually make an https request and we're done. I'm sure anyone who's ever worked with a computer will know how to use it.

The next step we will weed out the 60%.

Use AES encryption

Keys: 12345678. The body becomes:

lK/I57sqpDl+2G6k88XGVbMtngdLI8raGZ0W2XWW0So=

Looks pretty good, a lot of people don't know where to start.
Maybe the rest will press F12 and skillfully search for key, finally find the key easily: 12345678.

Is it possible to remove another 20% from the remaining 40%?

Maybe HMAC

You write the sign function in some corner of nowhere, and add the sign to header. You can implement your own set of sign logic, for example, swapping several of them after MD5, which can be unusual and make it more difficult to crack.

import axios, { AxiosRequestConfig } from 'axios';
import * as crypto from 'crypto';

// Calculate MD5 hash
function calculateMD5(data: string): string {
    return crypto.createHash('md5').update(data).digest('hex');
}

// Sort a string in lexicographical order
function sortString(str: string): string {
    return str.split('').sort().join('');
}

// Swap the front and back segments of a string
function swapSegments(str: string): string {
    const midpoint = Math.ceil(str.length / 2);
    return str.substr(midpoint) + str.substr(0, midpoint);
}

// Create an Axios instance
const instance = axios.create();

// Add request interceptor
instance.interceptors.request.use((config: AxiosRequestConfig) => {
    // Check if there is request data
    if (config.data) {
        // Convert request data to a string
        const bodyString = JSON.stringify(config.data);
        // Sort request data in lexicographical order
        const sortedBody = sortString(bodyString);
        // Calculate the MD5 hash of the sorted request data
        const md5 = calculateMD5(sortedBody);
        // Swap the front and back segments of the MD5 hash
        const swappedMD5 = swapSegments(md5);
        // Modify the request body to the swapped MD5 hash
        config.data = swappedMD5;
    }

    // Create a sign from the swapped MD5 hash
    const sign = crypto.createHash('md5').update(swappedMD5).digest('hex');
    // Add the sign to the request headers
    config.headers['Sign'] = sign;

    return config;
}, (error) => {
    return Promise.reject(error);
});

// Send a request
instance.post('https://api.example.com/data', { key1: 'value1', key2: 'value2' })
    .then((response) => {
        console.log(response.data);
    })
    .catch((error) => {
        console.error(error);
    });

Maybe someone looked for the reason for the sign field generation and spent a lot of time and then gave up.
No matter what encryption method is used, the JavaScript code that can be read is always easy to crack for somebody.

Code obfuscation

We can use variable renaming, string encoding, control flow obfuscation, and other techniques to make it more difficult to crack, but we can't escape the debugger after all.

HOTP

One of the fun ideas that came to me was to use HOTP. We can generate a one-time key every 30s to encrypt the data. However, the retry mechanism needs to be perfected, as the request is likely to be refreshing the password boundary of the refresh key.

import axios, { AxiosRequestConfig } from 'axios';
import * as crypto from 'crypto';

// Generate HOTP key
function generateHOTPKey(): string {
    const key = crypto.randomBytes(16).toString('hex'); // Generate a random key
    return key;
}

// Encrypt data using HOTP key
function encryptData(data: any, key: string): string {
    const cipher = crypto.createCipher('aes-256-ctr', key);
    let encryptedData = cipher.update(JSON.stringify(data), 'utf8', 'hex');
    encryptedData += cipher.final('hex');
    return encryptedData;
}

// Axios middleware for generating and using HOTP key
async function hotpMiddleware(config: AxiosRequestConfig): Promise<AxiosRequestConfig> {
    // Generate a new HOTP key every 30 seconds
    const key = generateHOTPKey();

    // Encrypt POST data if present
    if (config.method?.toLowerCase() === 'post' && config.data) {
        const encryptedData = encryptData(config.data, key);
        config.data = encryptedData;
    }

    return config;
}

// Create an Axios instance with the middleware
const instance = axios.create();
instance.interceptors.request.use(hotpMiddleware);

// Send a request
instance.post('https://api.example.com/data', { key1: 'value1', key2: 'value2' })
    .then((response) => {
        console.log(response.data);
    })
    .catch((error) => {
        console.error(error);
    });

The above does not refine the logic of generating a key in 30s, please note.

Web assembly

Using WebAssembly to compile a POST data encryption program enhances data encryption security. By encapsulating both the encryption key and logic within a WebAssembly module, it effectively deters reverse engineering and decryption attempts. Here's a breakdown:

Write Encryption Logic: Develop encryption logic in languages like C/C++, employing common encryption algorithms such as AES, RSA, etc. This logic will accept data and keys, returning encrypted data.
Compile to WebAssembly Module: Utilize tools like Emscripten to compile C/C++ code into a WebAssembly module. This encapsulates encryption algorithms and critical keys into a separate binary file, making them less susceptible to easy viewing or modification.
Integrate into Frontend App: Load and utilize the compiled WebAssembly module within the frontend application. Interact with WebAssembly via JavaScript to pass data for encryption, sending the encrypted data to the server afterward.
Protect Keys: Minimize exposing keys on the frontend. Techniques like generating keys on the server and transmitting them securely to the frontend or using one-time keys can enhance security.
Monitor and Update: Regularly monitor frontend application security, updating the WebAssembly module promptly to address potential vulnerabilities or weaknesses.

Do you have a better way to secure the API?