This topic contains 14 replies, has 0 voices, and was last updated by chanarbon 7 years, 4 months ago.

  • Author
    Posts
  • #6990 Score: 0

    jwebbstevens
    • Contributions: 0
    • Level 1

    Hello,

    We’re having trouble with the code that we’re sending for Token Based Authentication. Was curios if others had troubles intially

    I believe we have all the settings right on the NetSuite side and to me this request looks written correctly per the spec NS provided in HELP. We’re still getting a login error though on the callback.

    Specific details removed for obvious reasons but can anyone see anything structurally in correct with this?

    What is sent:

    < ?xml version="1.0" encoding="UTF-8"?>

    REMOVED FOR OBVIOUS REASONS

    REMOVED FOR OBVIOUS REASONS

    REMOVED FOR OBVIOUS REASONS

    REMOVED FOR OBVIOUS REASONS

    1473191911957

    REMOVED FOR OBVIOUS REASONS

    false

    2

    inventoryItem

    What is received:

    < ?xml version="1.0"?>

    soapenv:Server.userException

    Invalid login attempt.

    USER_ERROR Invalid login attempt.

    sb-partners-java052.svale.netledger.com

    For a sanity check here are the settings we have all appear to be correct:

    1. User is assigned a Web Services Only specific role

    2. Integration Record is setup (with both TBA and User/PW setup, figured we’d just uncheck User/PW once TBA is functioning)

    3. Even setup a User Access Token with the above settings too.

    4. Web Services Role has following permissions: Web Services, Log in Using Access Tokens, Web Services Only Role
    This is a cached copy. Click here to see the original post.

  • #6991 Score: 0

    david.smith
    • Contributions: 0
    • Level 1

    Have you tried removing the “webservices role only” from the role?

    TBA needs a role that has access like the UI.

  • #6992 Score: 0

    jwebbstevens
    • Contributions: 0
    • Level 1

    That’s interesting David. I didn’t know that but I’m not sure that’s entirely correct. We have multiple other accounts utilizing TBA and all are WS only with no UI access. So I don’t think that’s it. I think it relates to the structure of the code being thrown at NS TBA but am not sure.

    Was that mentioned in the documentation in NetSuite that it had to be UI access? Kind of defeats the purpose if that’s the case but sometimes the documentation contradicts the reality.

  • #6993 Score: 0

    david.smith
    • Contributions: 0
    • Level 1

    I don’t do much with webservices and I’ll never claim to always be right. I’m more of a RESTLet guy and I’ve done a lot of them. I only use TBA for connections now for security reasons.

    If you want to test your TBA, create a sample restlet and use something like the Chrome Postman to test the connection. Shouldn’t take more than 15 minutes to do.

    Again, I’m not a webservices guy but I’m seeing differences in what I send vs. what you have given. Check these values:

    Realm: netsuite account number

    Nonce: unique txt string

    You also seem to be missing the consumer key and token secret. But don’t shoot me if I just don’t understand. Sorry, I don’t think I’m helping much.

  • #6994 Score: 0

    jwebbstevens
    • Contributions: 0
    • Level 1

    You’ve responded so that helps We push people to use TBA as much as they can absorb but some are die hards and want to stick with plain jane user/pw. We’ll take a look at these details provided. Thanks again.

  • #6995 Score: 0

    chanarbon
    • Contributions: 0
    • Level 1

    Hi Justin,

    The scenario would either be similar to Divid’s statement of the web services only checkbox or the computation of the signature is not the same as the one in SuiteAnswers ID 44241 https://netsuite.custhelp.com/app/an…il/a_id/44241/

  • #6996 Score: 0

    chrisatsc
    • Contributions: 0
    • Level 1

    Justin,

    Did you ever get to the root of this issue? Seeing the same results here, not sure why (and debugging is nigh impossible).

    PHP code for generating the TokenPassport:

    Code:

    protected function getNonce()
    {
    $lowercase = range(‘a’, ‘z’);
    $uppercase = range(‘A’, ‘Z’);
    $numbers = range(0, 9);

    $chars = array_merge($lowercase, $uppercase, $numbers);

    $nonce = ”;
    for ($i = 0; $i $val)
    {
    $str .= $val . ‘&’;
    }
    $str = substr($str, 0, strlen($str) – 1);
    $key = $nsconsumer[‘secret’] . ‘&’ . $nstoken[‘secret’];
    return base64_encode(hash_hmac(‘sha1’, $str, $key));
    }

    public function setTokenPassport($nsaccount, $nsconsumer, $nstoken)
    {
    $vals = [
    ‘account’ => $nsaccount,
    ‘consumerKey’ => $nsconsumer[‘key’],
    ‘token’ => $nstoken[‘key’],
    ‘nonce’ => $this->getNonce(),
    ‘timestamp’ => time()
    ];
    $this->passport = new TokenPassport();
    $this->passport->account = $vals[‘account’];
    $this->passport->consumerKey = $vals[‘consumerKey’];
    $this->passport->token = $vals[‘token’];
    $this->passport->timestamp = $vals[‘timestamp’];
    $this->passport->nonce = $vals[‘nonce’];

    $this->passport->signature = new TokenPassportSignature();
    $this->passport->signature->_ = $this->getSignature($vals, $nsconsumer, $nstoken);
    $this->passport->signature->algorithm = ‘HMAC_SHA1’;
    }
    SOAP Request:

    Code:

    false
    true
    200

    XX
    XX
    XX
    XX
    XX
    XX

    2016-10-31T20:10:04.000+00:00
    2016-12-14T19:30:51.000+00:00

    Receiving the same “Invalid login attempt” error message (SOAPFault).

  • #6997 Score: 0

    jwebbstevens
    • Contributions: 0
    • Level 1

    No dice yet Chris. Funny I have this on my docket for review later this week.

  • #6998 Score: 0

    chrisatsc
    • Contributions: 0
    • Level 1

    Thanks, Justin. I may just put in a ticket with support on this. I’ve got the SuiteScript OAuth stuff for the Token-Based Authentication working, but this SuiteTalk integration has proven to be elusive.

  • #6999 Score: 0

    chanarbon
    • Contributions: 0
    • Level 1

    Hi Justin,

    For the PHP code, I suggest you checkout the sample posted in the SuiteTalk sample application. On the PHP Toolkit download, it contains a sample token generation class which you could supply on your call. Based on the source code, the generation of signature is fine based on the algorithm/requirements established by NetSuite with the release of TBA for SuiteTalk.

    Check it out @ http://www.netsuite.com/portal/devel…ications.shtml

  • #7000 Score: 0

    jwebbstevens
    • Contributions: 0
    • Level 1

    Awesome. Thanks all!

  • #7001 Score: 0

    chrisatsc
    • Contributions: 0
    • Level 1

    Bitten by urlencode, or lack thereof.

    First request succeeds; now to figure out why the followup search request gets the same error message.

    Thank you Christian and Justin!

  • #7002 Score: 0

    chanarbon
    • Contributions: 0
    • Level 1

    Hi chrisatsc,

    More or less, urlencode is one of the most common pitfalls that we encounter from users reporting failure in TBA for WS. There’s always this SuiteAnswers article to checkout for that one https://netsuite.custhelp.com/app/an…il/a_id/44241/

  • #7003 Score: 0

    TheUsualSuspect
    • Contributions: 0
    • Level 1

    Originally posted by david.smith

    View Post

    I don’t do much with webservices and I’ll never claim to always be right. I’m more of a RESTLet guy and I’ve done a lot of them. I only use TBA for connections now for security reasons.

    If you want to test your TBA, create a sample restlet and use something like the Chrome Postman to test the connection. Shouldn’t take more than 15 minutes to do.

    Again, I’m not a webservices guy but I’m seeing differences in what I send vs. what you have given. Check these values:

    Realm: netsuite account number

    Nonce: unique txt string

    You also seem to be missing the consumer key and token secret. But don’t shoot me if I just don’t understand. Sorry, I don’t think I’m helping much.

    Hey David, I was on a call earlier with a NetSuite support who informed me that TBA authentication will reject your message if your timestamp is too out of date. I haven’t been able to 100% confirm it yet though. He seemed to imply that anything more than a couple seconds would fail. Due to this, you shouldn’t be able to perform requests from Postman or anything that doesn’t dynamically create and send your request immediately.

  • #7004 Score: 0

    chanarbon
    • Contributions: 0
    • Level 1

    oauth_timestamp should be in +/- 5 minutes for the request to work.

You must be logged in to reply to this topic.