Credentials problem RRS feed

  • Question

  • Hi all,

    When user submit job via .net API without credentials on console application - the console ask him for user and pass , but on my winform app the user cant see that console
    credentials request and it blocks him .
    Is there a way to skip that credentials request and  only throw exception on submit failure ?

    (Currently I call submitjob via another  thread with timeout -

                 mSubmitJobByIdDelegate submitJobByIdDelegate = mHPCServerHandle.ServerScheduler.SubmitJobById;
                IAsyncResult iASR = submitJobByIdDelegate.BeginInvoke(mServerJob.Id, hpcUserName, null, null, new object());
                if (!iASR.AsyncWaitHandle.WaitOne(5000))
                    throw new SubmitJobTimedOutException();

    How can I test user
    credentials via .net API without submitting jobs - so  only if user passed that test , he would be able to submit a job (without blocking).

    Best Regards ,
    Thursday, January 28, 2010 9:52 AM


All replies

  • If you are running a winform application, you can call the SetInterfaceModel(false, yourWndHandle) to make sure you get a credential dialog instead of the console prompt. This should solve the blocking issue.
    Friday, January 29, 2010 8:51 AM
  • thanks ,

    But I want to prevent user from spend  his time on preparing job data and then fail on job submission ,
    How can I test client credentials before job submission via .NET API ?
    Saturday, January 30, 2010 3:01 PM
  • Hi Shay,

    I don't know the design of your application, but I think the answer to your question depends on what you want the application to do if it does test the credentials and they turn out to be incorrect. That is, will the application display a dialog box asking the user to fix their credentials somehow, or will the application provide a means for entering the credentials?

    Also, are you concerned mainly with detecting a situation where the cached credentials are stale, or perhaps just whether they have been cached at all?


    Wednesday, February 17, 2010 8:19 AM
  • Hi Patrick , 

    In my application the client has 3 different options 

    - make computation locally 
    - send  computation  to our hpc 
    - send  computation  to ms hpc 

    Before the client decide where to do his computation - he can test the hpc servers connectivity . 
    I wonder how can I add to that connectivity test - hidden credentials test , so client would know for sure that he could submit jobs to ms hpc  server .
    (Currently on that connectivity test ,  I test credentials with a dummy job submission )



    Wednesday, February 17, 2010 9:43 AM
  • Hi Shay,

    Are you trying to test two things here: (i) connectivity; and (ii) cached credentials, or are you just testing for cached credentials?

    If your application just needs to make sure that the job submit will not fail because the credentials were not cached, then will Yiding's suggestion above do what you want? i.e. If the credentials are not cached when a job is submitted, it will allow a credentials dialog to appear, and then the user can enter their credentials and have them cached for future job submissions.


    Thursday, February 18, 2010 7:03 PM
  • Hi Patrick , 

    I just want testing cached credentials without submitting a dummy job .



    Sunday, February 21, 2010 8:03 AM
  • Hi Shay,

    Sorry for the delay getting back to you again. We've discussed this scenario and, unfortunately, there's no way to test the already cached credentials without submitting a job. It's something we can consider in future.

    However, users can also cache their credentials from the command line using the "cluscfg setcreds" command, and that command does test the username/password before caching them. If necessary, your application could gather the username and password and then run the "cluscfg setcreds" command. The "cluscfg setcreds" command then returns an errorlevel of 1 if the username/password are incorrect; or 0 if they are correct.


    cluscfg setcreds /user:mydomain\myusername /password:MyPaSsWoRd


    Monday, March 1, 2010 11:44 PM
  • Thanks ! 

    • Marked as answer by Shay_Segev Thursday, March 18, 2010 9:13 AM
    Thursday, March 18, 2010 9:13 AM