I am using alfresco default web script to get a ticket for a user but i am not sure till when this obtained ticket is valid.
Also i am extracting ticket is from obtained XML response of alfresco default login web script.
Does a ticket has any expiry date or once a ticket is obtained, it will not expire till session expiry?
The following property set on the Alfresco repository, along with its default value, configures the ticket life span to be one hour:
authentication.ticket.validDuration=P1H
You can override such property in the usual way. Meaningful values are described in the Duration class:
* The lexical representation of duration is
* PnYnMnDTnHnMnS.
*
* P is a literal value that starts the expression
* nY is an integer number of years followed by the literal Y
* nM is an integer number of months followed by the literal M
* nD is an integer number of days followed by the literal D
* T is the literal that separates the date and time
* nH is an integer number of hours followed by a literal H
* nM is an integer number of minutes followed by a literal M
* nS is a decimal number of seconds followed by a literal S
Please note that by default successful usages of a ticket will renew its validity, meaning that given a ticket validity of one hour, if you authenticate, say, a web script call using the ticket after 59m from its generation, its validity will be extended to another hour.
As the ticket lifecycle is completely configurable, have a look at the ticketComponent Spring bean defined in authentication-services-context.xml to see the available options (e.g. setting oneOff to true to only allow one single use of a given ticket).
The best way to handle alfresco authentication tickets is to handle it manually. E.g. for getting a ticket, use OOTB web script.
http://localhost:8080/alfresco/service/api/login?u=admin&pw=admin
which return ticket such as TICKET_29ced6613a114294fa4bb9e67bf663112076f3d9 (needs to be extracted).
Now when using this ticket for any kind of operation, try to verify ticket validity using OOTB alfresco web script.Note that this is a HTTP GET method based web script
GET /alfresco/service/api/login/ticket/{ticket}
http://localhost:8080/alfresco/service/api/login/ticket/TICKET_29ced6613a114294fa4bb9e67bf663112076f3d9?alf_ticket=TICKET_29ced6613a114294fa4bb9e67b663112076f3d9
Thing to note here is that you need to authenticate this web script also by appending ?alf_ticket={ALFRESCO_TICKET} without which it will not work.
Finally when you are done with your things, always log out using OOTB alfresco logout web script. Note that this is a HTTP DELETE method based web script
DELETE /alfresco/service/api/login/ticket/{ticket}).
http://localhost:8080/alfresco/service/api/login/ticket/TICKET_29ced6613a114294fa4bb9e67bf663112076f3d9?alf_ticket=TICKET_29ced6613a114294fa4bb9e67bf663112076f3d9
Again you need to authenticate this web script also by appending ?alf_ticket={ALFRESCO_TICKET} without which it will not work.
This way you can ensure proper authentication as well as system will not be overburdened with stale tickets.
P.S. http://wiki.alfresco.com/wiki/Repository_RESTful_API_Reference#Logout
Related
The documentation about Client ID states that it must be a UUID
Example usage: cid=35009a79-1a05-49d7-b876-2b884d0f825b
But when looking at the calls that analytics.js is issuing, I see that the value has another format:
cid:714937391.1406537193
What are those values? and how are they generated? Can I use the same value if I want to append events to that session from a different application?
Is the Client ID used as the session identifier?
The documentation is a bit misleading. The client ID doesn't technically need to be a UUID hash in that format. It's merely suggesting that format to help people avoid generating duplicate client IDs by accident.
The format of the client ID in analytics.js is a randomly generated 31-bit integer followed by a dot (".") followed by the current time in seconds.
If you wanted to generate a client ID in this format yourself (for whatever reason) you could do something like the following:
var cid = Math.floor(Math.random() * 0x7FFFFFFF) + "." + Math.floor(Date.now() / 1000);
To answer your other question, yes, you can use the same client ID in a server-side Measurement Protocol hit as you find in the cookie generated by analytics.js and the sessions will be linked.
Furthermore, if you wanted to make sure your server-side hits were as closely linked to your client-side hit as possible, you should also use the User Agent and IP override fields, which are new to the measurement protocol. If you don't, then all the geo data for your server-side hits will look like it came from wherever your server is located.
UPDATE
Also, in case it's not clear how to get the client ID from JavaScript, here's what the documentation recommends:
ga(function(tracker) {
var clientId = tracker.get('clientId');
});
Note that it recommends not reading the data directly from the cookie.
We use Captcha control in a registration form that we make full client validation for all fields in JavaScript ( JQuery ) beside server validation ..
I tried a lot of ways but all will write the Captcha value in JavaScript that can be accessed by anyone :(
I search if is there any way that allow me validate Captcha value in client side using JQuery in secure way or it can't be done ?
It cannot be done.
Javascript is client-side, as you know, and any code client-side has to be treated as potentially compromised as you don't have control over it.
At best, you could resort to sending up a salted hash of the value along with the salt, but even that in itself could be used to test guess values before actually submitting it.
Everything else relies on calls to the server.
As per comment request, here's the general idea:
Firstly, on the server, calculate a random string to be used as the salt. This should be roughly unique every request. The purpose of this string is to prevent rainbow table attacks.
Now, saving this string separately, but also create another string that is the concatenation of random string and the Captcha answer. Of this new combined string you generate the hash (for example, SHA-1) of it.
using System.Web.Security;
...
string hashVal = FormsAuthentication.HashPasswordForStoringInConfigFile(combined, "SHA1");
Both the random string and the hash value need to be placed in the page for the javascript to be able to read.
On the client side, when a user answers the Captcha, take the random string and concatenate it with the answer (getting the idea here?). Taking this string, you can use something like the SHA-1 JQuery plugin to hash it and compare it with the pre-computed hash you sent up.
hashVal = $.sha1(combinedString)
If it matches, it is (almost) certainly the correct answer. If it doesn't, then it is 100% the wrong answer.
you could use ajax to post the current value to the server, which would respond true or false. that would keep you from doing a real post and also from giving away the catpcha's value in html.
My solution )) Every time when page shows captcha to the user, you can dynamically generate obfuscated JavaScript functions(i think the best way 5 or 10).
For example, one function(or 3)) ) can set cookies with pregenerated hash(server returns it)(from real value of the captcha), other functions must realize server side algorithm to check value which user's typed. I can say that it works for 100%, because it is very hard to parse dynamically javascript + we set user cookies on client side(It is very hard for Bots's to find out where and how you set and check cookies), by using JavaScript.
I want find a platform/language agnostic solution to ensuring the origin of a FORM POST is from an expected source. I.e. Page1.aspx posting to Page2.php within the same web site.
Specifically what I am attempting to do here is to prevent request forgery.
Use a hidden field in your form, which contains a token your app generated. Store the token in the user session. When the form is submitted, your app will check that the value of the hidden field is identical to the value stored in the user session.
If it is identical, then you know the submitted form comes from where it is expected to come.
Old Thread, but might still be useful.
If you do not have session info set (best option) then you can include a hidden field with an encrypted timestamp then compare it (after de-crypt) to the current time on the process end to make sure it is relatively close and thus as recent as you deem necessary.
You could include into the form a hidden field which would be the SHA1Hash("some-secret" + Remote_IP + PerSessionSecret).
The PerSessionSecret is something you autogenerate in the beginning of the session. "some-secret" is a global secret value - which will help a little bit in case the randomly generated PerSessionSecret turns out not to be very random enough.
Then do the same calculation upon the form submission and you know it's most probably submitted from the same client that it was sent to. (Of course, if you have multiple clients behind the single address, like a proxy or a NAT, you can not distinguish between them reliably).
For a Web Application I'd like to generate an email validation link and send it to the user. Like on many public websites, the user should click it to validate his email address. Looks similar to this:
http://www.foo.bar/validation?code=421affe123j4h141k2l3bjkbf43134kjbfkl34bfk3b4fkjb43ffe
Can anybody help me with some hints about the proper generation of those validation tokens? Googling best practices turned out to be more difficult than I though it would be. The links should:
... not require the user to log in first.
... not reveal any login credentials to keep the application secure
... allow me as a developer to efficiently validate the token. I'm pretty sure I need a way to extract the user identifier out of the code to meet this criteria. Don't I?
Furthermore, would you go for a random code, which is saved somewhere, or a generated code which I can recalculate for validation?
Thanks for any replies!
Matthias
P.S. I'm working with ASP.NET 3.5, in case there's an out-of-the-box feature to perform this.
Some suggestions to get you started:
Use GUIDs
Use some sort of salted hash (MD5, SHA1, etc)
Use a random string of characters (the more characters the less likely you'll have collisions)
Store it in a database temporarily, and timestamp it so that it expires after a certain period of time
The simplest way to do it is generate a GUID, store that in the database tying it to their user account and then give them a time-frame within which to click a link with that GUID in.
That validates they are the correct person without making the URL calculable whilst making it resistant to dictionary style attacks.
I construct the hash in a way that can be re-created:
code = MD5( my_hash + user_email + register_timestamp )
Then send a link to http://example.com/validation/?code = 4kj34....
Validation does a lookup like:
SELECT id
FROM users
WHERE
MD5( CONCAT( my_hash, user_email, register_timestamp ) ) = code
AND activated = 0
If you get a single result, update their 'activated' field and sign them in. You can also do some math on their 'register_timestamp' field for a poor man's TTL
I would probably use a Guid. Just create a Guid (by calling Guid.NewGuid()), store it as the validation token for that user, and include it in the validation link.
I have an interesting problem, I am writing a password management webpage/service and I am trying to find a way to determine when a user's password is going to expire so I can manually reset their other passwords with it and send out an email, etc.
The problem I'm having is that when trying to loop through my users I'm getting the bulk of them not having a pwdlastset attribute so I can't determine when it's going to expire.
So I guess I am looking for ideas on a good way to check for when a user's password is going to expire aside from using the pwdlastset property and calculating the time left.
Thanks a bunch.
It's actually quite a bit more complicated than you might think at first...
in order to know how long a password can be valid, you need to read a "domain policy" and find out that way
Then:
if the user has the "UF_DONT_EXPIRE_PASSWD" flag set in his "userAccountControl", his password will never expire
if the "pwdLastSet" value (a "ADSLargeInteger" or Int64 value, which is rather tricky to read in the first place) is 0, the user will have to change his password the next time he logs on
if the "pwdLastSet" value is -1, the password has never been set
only if none of the above are true, then the "pwdLastSet" value contains the date when the password was last set, to which you can add the "MaxPasswordAge" from the domain policy, and this will give you the date when the user's password is going to expire
Phew! Did you think it would be this tricky? :-)
Marc
PS: If you're serious about .NET based AD programming, you ought to have this book:
The .NET Developer's Guide to Directory Services Programming
The book contains all the goodies like determining user's password expiration dates, determining user account lockout state and much much more - highly recommended! Joe and Ryan did an outstanding job getting all this information together and explaining it so that even an average Joe programmer like myself can understand it :-)
As far as I know, if pwdlastset is zero or missing, the user is either required to change their password at the next logon or their account is setup with a non-expiring password. Could this be the cause of what you are seeing?
Here's another approach:
public static DateTime GetPasswordExpirationDate(UserPrincipal user)
{
DirectoryEntry deUser = (DirectoryEntry)user.GetUnderlyingObject();
ActiveDs.IADsUser nativeDeUser = (ActiveDs.IADsUser)deUser.NativeObject;
return nativeDeUser.PasswordExpirationDate;
}
You'll need to add a reference to the ActiveDS COM library typically found at C:\Windows\System32\activeds.tlb.