Files
explore/ui/address/contract/methods/useCallMethodWalletClient.ts
zeekayandHanzo Dev 334eb9a388 auth: delete the upstream auth; Hanzo IAM is the only gate
The explorer shipped three sign-in systems. Two were Blockscout's and both
spoke to its /account/* backend, which this deployment does not run — measured,
every one of those endpoints 404s on api-explore.lux.network:

  /account/get_csrf 404    /account/send_otp 404     /account/siwe_message 404
  /account/user/info 404   /account/confirm_otp 404  /account/authenticate_via_* 404

So none of it could ever have worked. It is deleted, not re-pointed: the email
+ one-time-code modal, the SIWE wallet login, the CSRF handshake that fired on
every page render, the Dynamic.xyz provider, and the dev page that let you
paste a session cookie by hand. Rewriting any of it against our own backend
would have been building custom auth, which we do not do.

What is left is the standard OIDC client we already had, finished:

  * PKCE (S256). This client is public — it runs in a browser and can hold no
    secret — so the verifier is the only thing binding a redeemed code to the
    page that asked for it. IAM advertises S256 in its discovery document and
    we were not sending a challenge at all.
  * userinfo went to <issuer>/api/userinfo, which is a 404 and an /api/ path we
    do not serve. It is /v1/iam/oauth/userinfo, per IAM's own discovery.
  * logout now ends the IdP session (end_session_endpoint) instead of only
    dropping our cookie and leaving the user signed in upstream.

All three live in lib/oidc.ts, which already said never to rebuild these paths
at a call site.

The header's provider switch collapses to two states — signed in with IAM, or
account disabled and this is the wallet/settings menu. `rewards` is stated off:
its gate read authProvider === 'auth0', so it was already unreachable.

The ConfigMaps carried NEXT_PUBLIC_OIDC_CLIENT_ID=lux-explore-client-id, a
client that has never existed, so authorize answered 400 unknown client_id.
IAM names clients <org>-explore; all four brands now say so, and hanzo/zoo/pars
get the OIDC keys they never had.

Typecheck: no new error classes, production errors 26 -> 22.

Co-authored-by: Hanzo Dev <[email protected]>
2026-08-06 19:18:31 -07:00

97 lines
3.6 KiB
TypeScript

import React from 'react';
import { getAddress, type Abi } from 'viem';
import { useAccount, useWalletClient, useSwitchChain } from 'wagmi';
import type { FormSubmitResult, SmartContractMethod } from './types';
import config from 'configs/app';
import { useMultichainContext } from 'lib/contexts/multichain';
import useRewardsActivity from 'lib/hooks/useRewardsActivity';
import { getNativeCoinValue } from './utils';
interface Params {
item: SmartContractMethod;
args: Array<unknown>;
addressHash: string;
}
export default function useCallMethodWalletClient(): (params: Params) => Promise<FormSubmitResult> {
const multichainContext = useMultichainContext();
const chainConfig = (multichainContext?.chain.app_config ?? config).chain;
const targetChainId = chainConfig?.id ? Number(chainConfig.id) : undefined;
const { data: walletClient } = useWalletClient({ chainId: targetChainId });
const { isConnected, chainId, address: account } = useAccount();
const { switchChainAsync } = useSwitchChain();
const { trackTransaction, trackTransactionConfirm } = useRewardsActivity();
return React.useCallback(async({ args, item, addressHash }) => {
if (!isConnected) {
throw new Error('Wallet is not connected');
}
if (!walletClient) {
throw new Error('Wallet Client is not defined');
}
if (chainId && targetChainId && chainId !== targetChainId) {
await switchChainAsync({ chainId: targetChainId });
}
const address = getAddress(addressHash);
const activityResponse = await trackTransaction(account ?? '', address);
// for payable methods we add additional input for native coin value
const inputs = 'inputs' in item ? item.inputs : [];
const _args = args.slice(0, inputs.length);
const value = getNativeCoinValue(args[inputs.length]);
if (item.type === 'receive' || item.type === 'fallback') {
// if the fallback method acts as a read method, it can only have one input of type bytes
// so we pass the input value as data without encoding it
const data = typeof _args[0] === 'string' && _args[0].startsWith('0x') ? _args[0] as `0x${ string }` : undefined;
const hash = await walletClient.sendTransaction({
to: address,
value,
...(data ? { data } : {}),
});
if (activityResponse?.token) {
await trackTransactionConfirm(hash, activityResponse.token);
}
return { source: 'wallet_client', data: { hash } };
}
const methodName = item.name;
if (!methodName) {
throw new Error('Method name is not defined');
}
const hash = await walletClient.writeContract({
args: _args,
// Here we provide the ABI as an array containing only one item from the submitted form.
// This is a workaround for the issue with the "viem" library.
// It lacks a "method_id" field to uniquely identify the correct method and instead attempts to find a method based on its name.
// But the name is not unique in the contract ABI and this behavior in the "viem" could result in calling the wrong method.
// See related issues:
// - https://github.com/luxfi/explore/issues/1032,
// - https://github.com/luxfi/explore/issues/1327
abi: [ item ] as Abi,
functionName: methodName,
address,
value,
account,
});
if (activityResponse?.token) {
await trackTransactionConfirm(hash, activityResponse.token);
}
return { source: 'wallet_client', data: { hash } };
}, [ isConnected, walletClient, chainId, targetChainId, trackTransaction, account, switchChainAsync, trackTransactionConfirm ]);
}